Size: a a a

pgsql – PostgreSQL

2020 August 10

AN

Alexander Nikitin in pgsql – PostgreSQL
версия 11.3
источник

AN

Alexander Nikitin in pgsql – PostgreSQL
ну да, 4
источник

AW

Alexander Walther in pgsql – PostgreSQL
2flower _
column "t1.created_at" must appear in the GROUP BY clause or be used in an aggregate function
это значит что у вас column должен быть описан в GROUP BY, в вашем запросе так и есть.
Да, мне уже объяснили в чем я ошибался, спасибо :)
источник

AN

Alexander Nikitin in pgsql – PostgreSQL
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();)?
vacuum_cost_delay     | 0        
vacuum_cost_page_hit  | 1        
vacuum_cost_page_miss | 5        
vacuum_cost_page_dirty| 10        
vacuum_cost_limit     | 200
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Alexander Nikitin
версия 11.3
Нет бы результат SELECT показать... и почему не 11.8?
Я лично уже почти потерял интерес к дальнейшим выяснениям — вдруг это какой-то bug, которому уже полгода, а мы тут будем копаться? ;)
Если серьёзнее — просто по количеству tuples видно, что для dead tuples используется 1 Гб, почему — кто его знает...
Можете проверить причины по порядку, подсмотрев в исходный код фукнции lazy_space_alloc() в src/backend/access/heap/vacuumlazy.c
источник

AN

Alexander Nikitin in pgsql – PostgreSQL
Дак в селект попала куча строк которые начинаются на вакуум - показал только те, которые были в документе. Не 11.8 - да, это моя недоработка, пока другие более насущные вопросы пытался решить, не до подобных минорных обновлений было. Спасибо, попробую посмотреть.
источник

AN

Alexander Nikitin in pgsql – PostgreSQL
Видимо, в 11 версии этот файл где-то по другому пути лежит, буду искать
источник

AN

Alexander Nikitin in pgsql – PostgreSQL
Yaroslav Schekin
Какое-то это число row versions подозрительное, кстати... у Вас там точно не Windows? ;)
Я вот об этом:
> SELECT 178956685*6, 1024*1024*1024;
1073740110 | 1073741824

Неужто совпадение? Или на самом деле почему-то используется только один гигабайт памяти?
Ярослав, а откуда множитель 6 взялся?
источник

I

I C in pgsql – PostgreSQL
Привет всем!
после изменения pg_hba.conf нужно перезагружать бд или можно обойтись SELECT pg_reload_conf(); ?
в интернете почему-то информация разнится
источник

AN

Alexander Nikitin in pgsql – PostgreSQL
Или это количество байт на одну удалённую строчку в maintenanceworkmem?
источник

AN

Alexander Nikitin in pgsql – PostgreSQL
I C
Привет всем!
после изменения pg_hba.conf нужно перезагружать бд или можно обойтись SELECT pg_reload_conf(); ?
в интернете почему-то информация разнится
Можно без перезагрузки
источник

I

I C in pgsql – PostgreSQL
спасибо!
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
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
Дело в том, что:
#define MaxAllocSize  ((Size) 0x3fffffff) /* 1 gigabyte - 1 */
источник

AN

Alexander Nikitin in pgsql – PostgreSQL
хм, то есть смысла нет выделять больше чем 1 Гб в maintenance_work_mem?
источник

GS

Grigory Smolkin in pgsql – PostgreSQL
Alexander Nikitin
хм, то есть смысла нет выделять больше чем 1 Гб в maintenance_work_mem?
имеет смысл для ускорения создания индекса
источник

SU

Sergey Ufimtsev in pgsql – PostgreSQL
Ребят, всем привет, подскажите плиз. У меня есть таблица на 67 миллинов записей, общим весом где-то около террабайта, мне нужно как-то сдампить данные и отправить дамп на s3. Хотел бы узнать как такое можно сделать.
Пока у меня довольно топорное решение, делать запросы по несколько тысяч записей, загружать их в csv, сжимать и отправлять частсями на s3 и в поисках более оптимально решения решил обратиться сюда
источник

Ð

Ð in pgsql – PostgreSQL
Sergey Ufimtsev
Ребят, всем привет, подскажите плиз. У меня есть таблица на 67 миллинов записей, общим весом где-то около террабайта, мне нужно как-то сдампить данные и отправить дамп на s3. Хотел бы узнать как такое можно сделать.
Пока у меня довольно топорное решение, делать запросы по несколько тысяч записей, загружать их в csv, сжимать и отправлять частсями на s3 и в поисках более оптимально решения решил обратиться сюда
pg_dump + s3cmd
источник

SU

Sergey Ufimtsev in pgsql – PostgreSQL
Так, а я могу разбить дамп на несколько файлов объемом по 100 мегабайт?
источник

Ð

Ð in pgsql – PostgreSQL
но возможно лучше будет не дампить ее вообще, а бекапить просто файлы базы
источник

Ð

Ð in pgsql – PostgreSQL
Sergey Ufimtsev
Так, а я могу разбить дамп на несколько файлов объемом по 100 мегабайт?
оно само разбивает его на чанки при закачке
источник