кстати не вижу принципиальной разницы между ЕМС и регистрируемым почтовым отправлением (т.е. USPS Express и USPS Priority из штатов). Идут примерно одинаково, отслеживаются, только что домой не приносят
Что касается NAT, то надо просто лимит не слишком маленький ставить, чтобы не мешало нормальной работе. А при атаке лучше пусть сетка за NAT отключится, чем вообще весь апач
На нагруженных базах full вообще не делают т.к. это вызывает недоступность сервера на значительное время (например на linux.org.ru full работает более 10 минут, а база там маленькая по большому счету). Реальная выгода от него только если от update'ов база пухнет в разы, но это для постгресса в любом случае крайне плохая ситуация.
Insert'ы, ясное дело, не добавляют работы vacuum'у — вопрос в числе UPDATE/DELETE. Кстати в постгрессе update любого поля в строке (кортеже) вызывает создание новой версии всей строки с обновлением индексов по всем полям. Новые постгрессы научились этого не делать если удается найти место в том же блоке на диске, и на том спасибо.
На практике беда мультиверсионности в возможности сильного распухания базы при большом числе обновлений. Индексы растут вместе с данными базы, поскольку они содержит ссылки на все версии пока их не почистит vacuum.
Признак простой — если база сильно вырастает в процессе работы, то или она организована плохо, или задача не для нее. Особенно плохо если база после в процессе роста перестает помещаться в оперативную память, а если индекс перестает — то вообще беда (этого, кстати не так сложно добиться если использовать полнотекстовый поиск с gin-индексами).
> Exclusive lock накладывается *только* при vacuum full.
Для этого не надо читать мануал — достаточно попробовать на нагруженной базе. Да, обычный vacuum значительно «гуманнее» vacuum full, но он не проходит незаметным.
> Ну если у вас версионник плохо подходит для задач с большим количеством модифицирующих запросов, тогда даже и не знаю, что вы нам тут еще «откроете» инетресного, ждем :-)
Большой поток обновляющих запросов вызывает массу проблем у версионника, особенно при наличии индексов
Vacuum в что называется конфликтует с нормальными запросами — на таблице может работать или vacuum, или insert/update/delete (про select не уверен). Если идет большой поток обновляющих запросов, то при работе vacuum они будут вставать в очередь, а потом ломиться на исполнение всей пачкой. Так что тут важно точно угадать с периодом запуска vacuum.
Лично у меня от работы с постгрессом сложилось впечатление что для задач с большим потоком INSERT/DELETE он плохо подходит.
Что касается NAT, то надо просто лимит не слишком маленький ставить, чтобы не мешало нормальной работе. А при атаке лучше пусть сетка за NAT отключится, чем вообще весь апач
Insert'ы, ясное дело, не добавляют работы vacuum'у — вопрос в числе UPDATE/DELETE. Кстати в постгрессе update любого поля в строке (кортеже) вызывает создание новой версии всей строки с обновлением индексов по всем полям. Новые постгрессы научились этого не делать если удается найти место в том же блоке на диске, и на том спасибо.
На практике беда мультиверсионности в возможности сильного распухания базы при большом числе обновлений. Индексы растут вместе с данными базы, поскольку они содержит ссылки на все версии пока их не почистит vacuum.
Признак простой — если база сильно вырастает в процессе работы, то или она организована плохо, или задача не для нее. Особенно плохо если база после в процессе роста перестает помещаться в оперативную память, а если индекс перестает — то вообще беда (этого, кстати не так сложно добиться если использовать полнотекстовый поиск с gin-индексами).
Для этого не надо читать мануал — достаточно попробовать на нагруженной базе. Да, обычный vacuum значительно «гуманнее» vacuum full, но он не проходит незаметным.
> Ну если у вас версионник плохо подходит для задач с большим количеством модифицирующих запросов, тогда даже и не знаю, что вы нам тут еще «откроете» инетресного, ждем :-)
Большой поток обновляющих запросов вызывает массу проблем у версионника, особенно при наличии индексов
Лично у меня от работы с постгрессом сложилось впечатление что для задач с большим потоком INSERT/DELETE он плохо подходит.