Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Что делает full vacum?
|
|||
|---|---|---|---|
|
#18+
У меня есть таблица. id_data bigint NOT NULL DEFAULT nextval('ind_data_id_ind_data_seq'::regclass), md5_data character(32) NOT NULL, data_data text, zabral_1 boolean NOT NULL DEFAULT false, zabral_2 boolean, zabral_3 boolean Получается я ошибся при проектировании. Каждую запись надо долго обрабатывать, я поставил поля boolean когда обработка проходит, я туда труе пишу. Как я читаю на форуме получается, что при этом копируется вся запись целиком а старое место остается незанятым и редко когда целиком займется. Соответственно база пухнет. SELECT count(1) FROM my_tabl WHERE zabral_1 OR zabral_2 OR zabral_33; Строк 6 391 150, размер сначала (сгоряча) посмотрел только в pgadmin было: таблица 1568 мб, toast 69gb, индексы 857. Я провел обслуживание full (как я понимаю full vacum) делалось часа три, наверное, всех отключил нафиг. написал сообщение, типа почистил 1500 записей, хотя не понятно как, я вроде ничо не удалял. В итоге таблица 1559 мб, toast 70gb, индексы 360(857) мб. Вопрос, так что же делает full? В моем случае он просто реиндекс сделал за три часа, круто, чо... Более важный вопрос, как сжать таблицу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2016, 07:14 |
|
||
|
Что делает full vacum?
|
|||
|---|---|---|---|
|
#18+
зы забыл добавить результат селекта сколько раз запись обновлялась при смене boolean 1 840 490 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2016, 07:16 |
|
||
|
Что делает full vacum?
|
|||
|---|---|---|---|
|
#18+
azsx, а откуда вообще подозрение что база распухла? может там 70ГБ данных и есть. если toasted поле при update не меняется - строки в toast таблице не копируются (будет использован тот же oid, в самой таблице копия строки будет). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2016, 07:48 |
|
||
|
Что делает full vacum?
|
|||
|---|---|---|---|
|
#18+
автора откуда вообще подозрение что база распухла? потому что я понять не могу. В моей базе тоаст - это хтмл код страниц, с ограничением не более 100 мб (чаще меньше). Размер какой угодно, идет только добавление уникальных страниц. Удаления нет совсем. Мне писали, что если делать как я, то есть в эту же таблицу добавить часто изменяемые поля, например, zabral_1 boolean, то при каждом изменении этого поля проходит засорение таблицы данными, которые автовакумом чистятся только если эти записи сейчас в конце (хз в каком конце). Я провел полный вакум. 1. Значит данных так и есть 70 гб, раз ничего не почистилось, верно? 2. Почистить данные от апдейтов даже полным вакумом нельзя? 3. изменение полей буулеан на распухание таблицы от левых данных никак не влияет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2016, 08:47 |
|
||
|
Что делает full vacum?
|
|||
|---|---|---|---|
|
#18+
azsxУ меня есть таблица. id_data bigint NOT NULL DEFAULT nextval('ind_data_id_ind_data_seq'::regclass), md5_data character(32) NOT NULL, data_data text, zabral_1 boolean NOT NULL DEFAULT false, zabral_2 boolean, zabral_3 boolean Получается я ошибся при проектировании. Каждую запись надо долго обрабатывать, я поставил поля boolean когда обработка проходит, я туда труе пишу. Как я читаю на форуме получается, что при этом копируется вся запись целиком а старое место остается незанятым и редко когда целиком займется. Соответственно база пухнет. SELECT count(1) FROM my_tabl WHERE zabral_1 OR zabral_2 OR zabral_33; Строк 6 391 150, размер сначала (сгоряча) посмотрел только в pgadmin было: таблица 1568 мб, toast 69gb, индексы 857. Я провел обслуживание full (как я понимаю full vacum) делалось часа три, наверное, всех отключил нафиг. написал сообщение, типа почистил 1500 записей, хотя не понятно как, я вроде ничо не удалял. В итоге таблица 1559 мб, toast 70gb, индексы 360(857) мб. Вопрос, так что же делает full? В моем случае он просто реиндекс сделал за три часа, круто, чо... Более важный вопрос, как сжать таблицу? перед vacuum full имеет смысл сделать pgstattuple() на саму таблицу и на toast чтобы понять что там с незанятым местом. Вполне может быть что у вас ничего и не распухло особо (особенно если долгих транзакций не было а записи обновляются 2-4 раза за время жизни а не 2000-4000+ раз). -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2016, 08:50 |
|
||
|
Что делает full vacum?
|
|||
|---|---|---|---|
|
#18+
модуль pgstattuple, к моему сожалению, у меня не установлен и понять как его устанавливать я не могу. Также я ваще не могу понять как модули в postgres устанавливаются. Нет ли других методов? Правильно ли я понял, что если имеем запись char, text, boolean 1, boolean 2, boolean 3 и за всё время лишь иногда меняется boolean - то незанятое место не появляется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2016, 09:14 |
|
||
|
Что делает full vacum?
|
|||
|---|---|---|---|
|
#18+
azsx, pgstattuple есть в contrib. если он поставлен, то просто сделать create extension pgstattuple. еще раз: при update строки создается ее копия в таблице. значения полей, размер которых больше 2кб хранятся в отдельной toast таблице. в самой таблице вместо значения поля хранится chunk id, по которому это значение можно из toast таблицы собрать из кусков по 2кб. если при update toasted поля не менялись, то в toast таблице никаких изменений не будет. подробнее про toast см. документацию : During an UPDATE operation, values of unchanged fields are normally preserved as-is; so an UPDATE of a row with out-of-line values incurs no TOAST costs if none of the out-of-line values change. vacuum full может освободить место, занимаемое ненужными копиями строк (или свободное место внутри таблиц). он просто создает копию таблицы без лишнего мусора и удаляет старую таблицу. если автовакуум работает, не было массового обновления data_data, не было массового удаления строк из таблицы, не было большого числа обновлений data_data во время длинной транзакции то пухнуть сильно не должно. рекомендуется посмотреть размеры самых длинных data_data, например top 100 самых длинных значений в таблице. могут быть сюрпризы. хотя вот в среднем получается 10кб на запись, что может быть нормально для html страниц (не факт что они сжиматься будут в toast). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2016, 10:24 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=88&tid=1997083]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
| others: | 256ms |
| total: | 382ms |

| 0 / 0 |
