Это в один поток. Я сейчас молчу про потери при лишнем seq scan'е и сортировке таблицы. А если захотите асинхронно по каждому пустить — придется вытаскивать результат SELECT DISTINCT на клиента. А потом еще затрачивать время на открытие нового connection к базе для запуска очередного запроса.
Это замедлит вставку, а при ошибке, вставка вообще не пройдет. Если вставлять быстро (COPY в postgres), то триггер игнорируется. Вообщем-то с триггерами я всегда руководствуюсь простым правилом — если есть возможность избежать использования триггеров — выбирай ее всегда.
Я вам об одном сферическом коне, а вы мне о своем:).
>>решение кривое, т.к. если сервер не успевает обрабатывать FIFO
В примере не было FIFO, но мне не жалко, пусть будет.
>>то на нескольких процессах он должен la сервера поднять и затормозить работу сервера.
Угу, три ядра у нас простаивало, а теперь они заняты работой и усиленно тормозят работу сервера, да.
>>Такая задача решается мониторингом длины очереди и контролем при запуске скрипта того что старый завершен.
В примере так и делается. Просто когда скрипт перестает справляться, очередь начинает накапливаться.
Наверное не так в первый раз сказал. Такой вариант возможен и применим. Его минус — ребалансировка если вам нужно увеличить количество потоков (легко обходится если вы сразу создадите большее количество секций, чем используется) + накладные расходы связанные с самим секционированием.
Выше в комментариях идет дискуссия на этот счет. Более жизнеспособный пример habrahabr.ru/blogs/postgresql/76309/#comment_2217268, при котором индекс дает преимущество. Если идти по всей таблице в 4 потока — выигрыша по сути нет. Если в 16 — есть. Так что все зависит от задачи.
Да, тоже правильно. Можно еще bitmap индекс создать. А вообще если мы каждый раз чешем по всей таблице, то индекс выигрыш даст минимальный, а вот если появляется поле billed (как выше в комментариях), то ситуация меняется. В примере billed нет чтобы не отвлекать внимание от сути.
На самом деле этот прием я подглядел когда-то давно именно в биллинге (есть такой замечательный биллинг — БИС от петер-сервис, его Мегафон использует). У них отложенное применение скидок, и по таблице вызовов они идут в 8 или 16 потоков используя похожий индекс по полю % 8 или 16.
>>решение кривое, т.к. если сервер не успевает обрабатывать FIFO
В примере не было FIFO, но мне не жалко, пусть будет.
>>то на нескольких процессах он должен la сервера поднять и затормозить работу сервера.
Угу, три ядра у нас простаивало, а теперь они заняты работой и усиленно тормозят работу сервера, да.
>>Такая задача решается мониторингом длины очереди и контролем при запуске скрипта того что старый завершен.
В примере так и делается. Просто когда скрипт перестает справляться, очередь начинает накапливаться.
И выборка идет еще шустрее.