select * from table where (payer=1 or recipt=1) and date between d1 and d2; такой запрос

Обычное секционирование плохо ускоряет. pg_pathman умеет сам разливать данные из родительской таблицы по дочкам и ищет именно в той дочерней таблице, где эти данные лежат. Так что он поиск по ключу шаржированных радикально ускоряет. В нем можно шаржировать по хешу или по диапазонам

http://www.sai.msu.su/~megera/postgres/talks/novosib_pg.pdf прогрессивные ребята postgresql pro, прямо сейчас все это делают, а планы еще круче)

а эти шарды могут на разных серверах находится?

т.е. горизонтально масштабироваться

а эти шарды могут на разных серверах находится?

За счёт fdw - да. Но лично я не проверял

Ну и как будет строиться план по внешней таблице не могу сказать

пока, конечно, одного сервера хватает, но каждый месяц +2-3 млн

По опыту скажу, что pathman классно позволяет делать именно то, что заявлено - искать значения шардирования. Агрегация данных из кучи дочерних таблиц, например, дольше, чем из одной родительской (что логично)

надо еще почитать, не пойму в чем смысл этого шардирование. типа зачем разбивать таблицу, если она все равно на одном сервере будет

Вообще я сторонник, что лучше заранее все порезать на части по разным серверам, чем вырастить монстра с безумными объемами и поклоняться ему) Ребята в скайпе вообще все пилят через plproxy на разные сервера, раскладывая данные на базы по паре гб

если какой-то запрос должен просканить всю таблицу, то шардирование может знатно уменьшить объем скана

(не то чтобы я pathman пользовался, просто влез)

Ну разница в том, что таблица - это файл. И индекс - файл. И искать данные в файле в 1 Гбайт всяко быстрее, чем в 50 гб

т.е. запрос просто распараллеливается?

не параллелится, а идет в хранилище меньшего объема

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

ERROR: S client not available

надо только детали поизучать, как это делается

спасибо, это тоже ключевой вопрос, правда пока фуллтекст поиск приоритетнее, а потом и этим займусь

отличное введение в тему, кстати, https://habrahabr.ru/company/oleg-bunin/blog/309330/

Коллеги, кто знает сколько времени будет занимать переключение на следующий в списке синхронных стендбаев ? для версии 9.5 есть wal_sender_timeout (integer) - он будет для каждого лога по очереди ходить по всем стендбаям и ждать этот таймаут или один раз найдет рабочий и начнет на него писать синхронно ?

Коллеги, кто знает сколько времени будет занимать переключение на следующий в списке синхронных стендбаев ? для версии 9.5 есть wal_sender_timeout (integer) - он будет для каждого лога по очереди ходить по всем стендбаям и ждать этот таймаут или один раз найдет рабочий и начнет на него писать синхронно ?

Сразу, как только реплика догонет

а оно точно нужно эти 14 тыс значений?

а оно точно нужно эти 14 тыс значений?

еще раз запустил, 100 секунд ровно. да нужно, хотя вопрос хорошой)