|
|
|
Длительные транзакции
|
|||
|---|---|---|---|
|
#18+
Добрый день. Есть таблица (planet_osm_line) - 87 млн записей. Из этой таблицы путем типового запроса SELECT ... INTO TABLE ..., выполняется формирование новой таблицы. Запрос выполняется больше суток. Вопрос - как понять, что запрос выполняется, а не завис? Куда и как смотреть, что бы понять что вставка данных идет и нужно просто набраться терпения и дождаться результата? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2015, 12:42 |
|
||
|
Длительные транзакции
|
|||
|---|---|---|---|
|
#18+
big-trot, смотреть в pg_stat_activity поле waiting у строки с запросом, если оно false и status=active - значит запрос выполняется (но не значит что за разумное время завершится). понять, завершится ли можно по explain запроса. по top/iotop/iostat можно понять во что запрос упирается: в cpu или диски. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2015, 13:14 |
|
||
|
Длительные транзакции
|
|||
|---|---|---|---|
|
#18+
big-trot, Если есть в новой таблице поле, заполняемое последовательностью (напрbмер - serial), то можно смотреть значение последовательности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2015, 13:47 |
|
||
|
Длительные транзакции
|
|||
|---|---|---|---|
|
#18+
big-trot, В книге "PostgreSQL 9 Administration Cookbook" Simon Riggs, Hannu Krosing есть функция pg_relation_size_nolock которая показывает как узнать физический размер который занимает таблица на диске. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. далее используете следующее Код: sql 1. 2. 3. 4. в другом соединении выполняем команду Код: sql 1. теперь мы можем видеть в % как много еще осталось скопировать. Если же разделить полученный размер в байтах (pg_relation_size_nolock('table_dest'::regclass)) на среднюю ширину строки, то можно получить приблизительный объем вставленных строк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2015, 15:51 |
|
||
|
Длительные транзакции
|
|||
|---|---|---|---|
|
#18+
Ситуация несколько иная. Выражение SELECT ... INTO TABLE ... похоже не создает сразу таблицу в явном виде, потому что её не видно ни в одном из инструментов. Можно предположить, что таблица появится после выполнения всей операции в целом. В настоящий момент нет возможности обратиться к этой таблице и отследить как идет вставка. В pg_stat_activity процесс находится в активном состоянии. С помощью запроса select pg_database_size(current_database()) видно, что размер базы данных увеличивается. Не ясно, как понять когда процесс завершится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2015, 16:58 |
|
||
|
Длительные транзакции
|
|||
|---|---|---|---|
|
#18+
big-trot, Такие вещи сначала тестируют на тестовой базе (или если таковой нет на каком то разумном обьеме данных на боевой базе) чтобы иметь представление о времени выполнения. Сейчас вы это никак не узнаете. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2015, 17:07 |
|
||
|
Длительные транзакции
|
|||
|---|---|---|---|
|
#18+
На разумном объеме это все работает, потому что проверялось на меньшей геометрии (данные вставлялись для одного города). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2015, 17:12 |
|
||
|
Длительные транзакции
|
|||
|---|---|---|---|
|
#18+
big-trotВыражение SELECT ... INTO TABLE ... похоже не создает сразу таблицу в явном виде, именно поэтому я написал вам, что таблицу источник нужно создать заранее, отдельной командой в отдельном запросе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2015, 17:55 |
|
||
|
Длительные транзакции
|
|||
|---|---|---|---|
|
#18+
big-trotНе ясно, как понять когда процесс завершится. далее вы можете смотреть на время потраченное на запись определенного объема данных и зная каков общий объем примерно понять как долго еще будет идти процесс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2015, 17:57 |
|
||
|
Длительные транзакции
|
|||
|---|---|---|---|
|
#18+
Опытным путем пришел к следующей схеме работы с данными больших таблиц. 1. Если необходимо выполнить выборку данных из большой таблицы и результат направить в другую таблицу, то целесообразно результат запросы выгружать сначала в файл с помощью команды COPY, и далее той же командой COPY загрузить данные в предварительно созданную под эти данные таблицу. 2.Не рекомендуется использовать команду типа SELECT ... INTO TABLE. Данной выражение работает на несколько порядков медленнее. 3.Правда не пробовал вариант INSERT INTO ... SELECT... Осмелюсь предположить, что этот вариант равносилен SELECT ... INTO TABLE. На основании чего были сделаны выводы: Исходная таблица - 86 млн. записей. В результате выполнения запроса получено - 4 млн. записей. Время выборки и копирование результата в файл заняло чуть больше 4-х часов. Время вставки данных из файла в таблицу - секунды. Время выполнения команды SELECT ... INTO TABLE - запрос еще выполняется. Но уже время выполнения запроса в настоящий меряется сутками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2015, 18:31 |
|
||
|
Длительные транзакции
|
|||
|---|---|---|---|
|
#18+
big-trot, в общем случае так рекомендовать нельзя. провел тест ради интереса на 9.3 на тестовых данных (таблица узкая, 48 байт. на широких может быть иначе): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. copy в text формате стабильно 2 раза медленнее, в binary примерно так же. на аналогичной 10М таблице результаты примерно такие же. insert into кстати медленней select * into (т.к. ему нужно данные еще через wal прогнать, в отсутствии репликации остальные варианты в wal'ы писать не будут скорее всего). в unlogged таблицу примерно с такой же скоростью работает: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2015, 13:38 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38935154&tid=1998043]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
| others: | 218ms |
| total: | 367ms |

| 0 / 0 |
