Максим, добрый день (или ночь у вас в Австралии).

Ссылка в первом сообщении недоступна.

Это то, что вы создали:
https://github.com/koordinates/pg_comparator/blob/master/pg_comparator
?



Хочу установить эту штуковину под виндоус.


Подскажите пожалуйста, как это сделать?

plperl уже установлен.

grufos,

ваши пост прошел.

MelkijperМаксим, добрый день (или ночь у вас в Австралии).

Ссылка в первом сообщении недоступна.

Это то, что вы создали:
https://github.com/koordinates/pg_comparator/blob/master/pg_comparator
?
Нет, что-то другое.
Актуальный pgcompacttable вот здесь: https://github.com/dataegret/pgcompacttable

perplperl уже установлен.
Не нужен. Нужен только сам perl в ОС и DBI коннектор к pg для него. Со стороны базы - contrib pgstattuple, а plperl не нужен.

Не помню, тестировали ли под такой экзотикой как windows.

Спасибо, за оперативный ответ!

Оказалось plperl вообще не нужен, а я его именно для pgcompacttable хотел :)

По поводу первой ссылки, не вашей, меня комментарии насторожили, типа "я ненавижу перл" и тп.


Заранее прошу прощения за тупость, но что такое перл вообще не знаю и для постгреса никаких языков ни разу не устанавливал, пользовался из установленного по умолчанию...


Итак, ближе к делу.

Сделал: create extension pgstattuple.

>DBI коннектор к pg для него
пока ищу что это такое.


По ссылке https://github.com/dataegret/pgcompacttable/blob/master/bin/pgcompacttable огромный скрипт:



Я так понимаю что его надо сохранить как файл и вызывать perl.exe с этим скриптом, он на вход запросит параметры.
Правильно или я что-то опять не так понял?

Melkij,

пока получил ошибку о которой говорил grufos, сейчас попробую последовать его рекомендации.

grufosПопробовал выполнить и столкнулся с проблемой - функция getpwuid($<) (её просто нет в реализации под windows)
Поискав.. нашел решение - заменить на getlogin()
Заработало!
Попробовал на своей локальной БД (6 Гб). Всё отработало без ошибок.
У меня стоит PostgreSQL 9.4.1 (64 bit)
Возможно мой опыт использования на Windows будет кому-то полезен.



Сделал как вы сказали - действительно заработало!

Melkijper>DBI коннектор к pg для него
пока ищу что это такое.
libdbi-perl и libdbd-pg-perl
Для экзотики не скажу.


Ничего дополнительно не создавал, но к БД подключение есть.

Натравил на тестовую табличку 5 Гб с 99.99% мертвых строк.

Надеюсь получится...





Еще один важный вопрос: не держит ли этот скрипт snapshot БД на начало запуска? Т.е. будут ли хот апдэйты и вакуум отрабатывать на других таблицах для данных стрше времени старта скрипт? Ну вы поняли о чем я :)

Melkijper,

нет, не держит. Таблица обновляется крошечными пачками в отдельных транзакциях с паузами. Заметные по длительности транзакции возможны во время перестроения индексов (дефолтно после урезания размера таблицы), там create index concurrently без извращений - тут уж насколько ваше железо позволит быстро построить индекс.

Отлично!

Как раз хотел на счет индексов уточнить, есть ли возможность запустить без перестройки индексов? (чтоб их ночью, например отдельно перестроить)


Кстати, протестировал.

Я очень доволен результатом!


Вот что было:

Стало


Максим, большое спасибо!

Ваша утилита просто супер!!!


Я бы ее в контриб предложил включить!

MelkijperКак раз хотел на счет индексов уточнить, есть ли возможность запустить без перестройки индексов? (чтоб их ночью, например отдельно перестроить)
--no-reindex
У вас настолько плохие диски?


Плохие... Думаю перестройка индекса займет часов 8...

Еще у вас там вроде есть различные опции для уменьшения нагрузки на диск (nice или что-то похожее), будут ли они работать на windows ?

Melkijper,

ionice -c 3 пробуем вызвать для pid backend'а базы.
Это вас как windows админа надо спросить, есть ли у вас какие-нибудь средства для управления приоритетами i/o. Если есть - то проставьте приоритет backend процессу базы. Помнится pgcompacttable в начале работы даже выводит pid backend'а.


Так точно, выводит.




Еще важный вопрос: я так понял что compacttable можно запускать с удаленного сервера.

Будет ли в таком случае весь объем таблицы гоняться по сети туда-сюда?

Ну или примерно в % от объема таблицы сколько по сети гнать придется? И на сколько быстрая сеть нужна? Ну вы поняли о чем я спрашиваю :)

Melkij, добрый день.

Запустил на проме по 1 табличке.

Выполняется уже двое суток.


При этом выполнено около 5%.

Таблица объемная, около 300Гб постоянно апдэйтится и инсерется.



В связи с этим возник вопрос:


Я так понял что compacttable переносит данные со всех файлов в несколько первых, максимально заполняя их "живыми" данными.
При этом если будет хоть одна живая запись в конце файла, то он не очистится.

Получается что compacttable бесполезна при постоянных апдэйтах таблицы? Или я что-то не так понял и файлы таблицы все равно очистятся в итоге?

Maxim Boguk, добрый день.


В общем, отработала процедурка по огромной таблице.

Но уменьшила ее всего процентов на 5-7, при этом vacuum full уменьшает обычно в два-три раза.

Я все-же думаю это из-за того что выполняется очень долго, и данные, которые вставляются таблицу во время выполнения, не дают очистить файлы таблицы вакуумом, который выполняется по окончанию.


Есть три вопроса:



1) Хочется разобраться с механизмом перестройки индексов.

Я так понял что создается новый индекс конкарентли, с временным именем, затем старый удаляется и новый переименовывается в имя старого, который уделился. Так ли это?


2) Пересоздались ли индексы в этом случае?

В логе такие сообщения:





3) Имеет ли смысл после окончания процедуры перезапустить postgres и выполнять вакуум большой таблицы еще раз?

Сразу скажу, что у меня это ни на сколько не уменьшило объем таблицы, но я делал с перестройкой индексов, возможно, если не ждать перестройки 3-4 суток (--no-reindex), результат будет другой.

Alexiuspgcompacttable не умеет сжимать данные в toast'ах (база не дает в них делать изменения)




Maxim Boguk, добрый день.

Так ли это?

perAlexiuspgcompacttable не умеет сжимать данные в toast'ах (база не дает в них делать изменения)




Maxim Boguk, добрый день.

Так ли это?


Просто запустил по таблице размером поменьше и вот что в логе, в начале:

Statistics: 4793571 pages (13826429 pages including toasts and indexes), it is expected that ~33.200% (1591468 pages) can be compacted with the estimated space saving being 12.142GB.

Размер тоаст сейчас померяю конечно, но выполняться будет думаю недели две-три, до окончания не узнать.