AN
версия 11.3
Size: a a a
2020 August 10
AN
ну да, 4
AW
2flower _
column "t1.created_at" must appear in the GROUP BY clause or be used in an aggregate function
это значит что у вас column должен быть описан в GROUP BY, в вашем запросе так и есть.
это значит что у вас column должен быть описан в GROUP BY, в вашем запросе так и есть.
Да, мне уже объяснили в чем я ошибался, спасибо :)
AN
Yaroslav Schekin
Т.к. это обычный vacuum, то используется maintenance_work_mem.
Только почему-то используется 1 Гб, а Вы писали, что там 4, так?
А всякие настройки задержек — отсюда, на всякий случай : https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST
А какая это полная версия PostgreSQL (SELECT version();)?
Только почему-то используется 1 Гб, а Вы писали, что там 4, так?
А всякие настройки задержек — отсюда, на всякий случай : https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST
А какая это полная версия PostgreSQL (SELECT version();)?
vacuum_cost_delay | 0
vacuum_cost_page_hit | 1
vacuum_cost_page_miss | 5
vacuum_cost_page_dirty| 10
vacuum_cost_limit | 200
vacuum_cost_page_hit | 1
vacuum_cost_page_miss | 5
vacuum_cost_page_dirty| 10
vacuum_cost_limit | 200
YS
Alexander Nikitin
версия 11.3
Нет бы результат SELECT показать... и почему не 11.8?
Я лично уже почти потерял интерес к дальнейшим выяснениям — вдруг это какой-то bug, которому уже полгода, а мы тут будем копаться? ;)
Если серьёзнее — просто по количеству tuples видно, что для dead tuples используется 1 Гб, почему — кто его знает...
Можете проверить причины по порядку, подсмотрев в исходный код фукнции lazy_space_alloc() в src/backend/access/heap/vacuumlazy.c
Я лично уже почти потерял интерес к дальнейшим выяснениям — вдруг это какой-то bug, которому уже полгода, а мы тут будем копаться? ;)
Если серьёзнее — просто по количеству tuples видно, что для dead tuples используется 1 Гб, почему — кто его знает...
Можете проверить причины по порядку, подсмотрев в исходный код фукнции lazy_space_alloc() в src/backend/access/heap/vacuumlazy.c
AN
Дак в селект попала куча строк которые начинаются на вакуум - показал только те, которые были в документе. Не 11.8 - да, это моя недоработка, пока другие более насущные вопросы пытался решить, не до подобных минорных обновлений было. Спасибо, попробую посмотреть.
AN
Видимо, в 11 версии этот файл где-то по другому пути лежит, буду искать
AN
Yaroslav Schekin
Какое-то это число row versions подозрительное, кстати... у Вас там точно не Windows? ;)
Я вот об этом:
Неужто совпадение? Или на самом деле почему-то используется только один гигабайт памяти?
Я вот об этом:
> SELECT 178956685*6, 1024*1024*1024;
1073740110 | 1073741824
Неужто совпадение? Или на самом деле почему-то используется только один гигабайт памяти?
Ярослав, а откуда множитель 6 взялся?
I
Привет всем!
после изменения pg_hba.conf нужно перезагружать бд или можно обойтись SELECT pg_reload_conf(); ?
в интернете почему-то информация разнится
после изменения pg_hba.conf нужно перезагружать бд или можно обойтись SELECT pg_reload_conf(); ?
в интернете почему-то информация разнится
AN
Или это количество байт на одну удалённую строчку в maintenanceworkmem?
AN
Привет всем!
после изменения pg_hba.conf нужно перезагружать бд или можно обойтись SELECT pg_reload_conf(); ?
в интернете почему-то информация разнится
после изменения pg_hba.conf нужно перезагружать бд или можно обойтись SELECT pg_reload_conf(); ?
в интернете почему-то информация разнится
Можно без перезагрузки
I
спасибо!
YS
Alexander Nikitin
Ярослав, а откуда множитель 6 взялся?
Это sizeof(ItemPointerData)
А вообще, это я Вам всё наврал, извините — больше, чем 1 Гб, там не выделяется (когда я это запомню?). :(
См., например: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/commands/vacuumlazy.c;h=7c004185780d0183142ca23efba86d90b955522c;hb=d439e27d5f57df1365b53688daa367d56d55599d#l2090
Дело в том, что:
А вообще, это я Вам всё наврал, извините — больше, чем 1 Гб, там не выделяется (когда я это запомню?). :(
См., например: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/commands/vacuumlazy.c;h=7c004185780d0183142ca23efba86d90b955522c;hb=d439e27d5f57df1365b53688daa367d56d55599d#l2090
Дело в том, что:
#define MaxAllocSize ((Size) 0x3fffffff) /* 1 gigabyte - 1 */
AN
хм, то есть смысла нет выделять больше чем 1 Гб в maintenance_work_mem?
GS
Alexander Nikitin
хм, то есть смысла нет выделять больше чем 1 Гб в maintenance_work_mem?
имеет смысл для ускорения создания индекса
SU
Ребят, всем привет, подскажите плиз. У меня есть таблица на 67 миллинов записей, общим весом где-то около террабайта, мне нужно как-то сдампить данные и отправить дамп на s3. Хотел бы узнать как такое можно сделать.
Пока у меня довольно топорное решение, делать запросы по несколько тысяч записей, загружать их в csv, сжимать и отправлять частсями на s3 и в поисках более оптимально решения решил обратиться сюда
Пока у меня довольно топорное решение, делать запросы по несколько тысяч записей, загружать их в csv, сжимать и отправлять частсями на s3 и в поисках более оптимально решения решил обратиться сюда
Ð
Ребят, всем привет, подскажите плиз. У меня есть таблица на 67 миллинов записей, общим весом где-то около террабайта, мне нужно как-то сдампить данные и отправить дамп на s3. Хотел бы узнать как такое можно сделать.
Пока у меня довольно топорное решение, делать запросы по несколько тысяч записей, загружать их в csv, сжимать и отправлять частсями на s3 и в поисках более оптимально решения решил обратиться сюда
Пока у меня довольно топорное решение, делать запросы по несколько тысяч записей, загружать их в csv, сжимать и отправлять частсями на s3 и в поисках более оптимально решения решил обратиться сюда
pg_dump + s3cmd
SU
Так, а я могу разбить дамп на несколько файлов объемом по 100 мегабайт?
Ð
но возможно лучше будет не дампить ее вообще, а бекапить просто файлы базы
Ð
Так, а я могу разбить дамп на несколько файлов объемом по 100 мегабайт?
оно само разбивает его на чанки при закачке