Timosha

ак отфильтруйте то что вам не надо явно

SELECT * FROM table WHERE created_at <= $1 and id != $2

если в момент "зависания" количество запросов не изменятся, то есть их внезапно не становится в 10 раз больше. смотрите где именно затык, I/O, CPU? Какие запросы волполняются в этот момент, сколько памяти потребляют процессы, сколько активных процессов postgresql в этот момент? Что происходит с дисками? запись/чтение?
Судя по конфигу, при незначительном объёме изменений может происходить запись checkpoint. Уменьшите checkpoint_segments = 1024 раз в 10
work_mem = 768MB тоже слишком много. 10МБ более чем достаточно для большинства задач
а default_statistics_target = 50 наоборот мало, учитывая дефолтное значение - 100, поставьте 200-300.
Не понятен мотив подкрутки параметров планировщика, зачем?

вообще так нельзя
в данном случае можно использовать наследованные таблицы www.postgresql.org/docs/9.3/static/ddl-inherit.html

на самом деле вы вставляете text а не integer,

insert into a values ('1', 2) except select b, c from a

либо Вы, либо Ваш драйвер неверно передаёт тип данных. можете приводить типы явно:

insert into a values ('1'::int, 2) except select b, c from a

а кроме pgAdmin особо и нет ничего :) и не так уж он и ужасен как может показаться на первый взгляд :)

примерно так:

pg_query('begin');
pg_query('insert');
pg_query('rollback');

заведите для новых клиентов базу поменьше, делайте так чтобы выборки поднимали как можно меньше данных и не использовали рандомное чтение с диска. руками поднимайте необходимые данные в дисковый кэш и shared buffers. вариантов борьбы много, на всех не in-memory базах скорость будет упираться в скорость случайного чтения с винчестеров в случае запроса не поднятых в память данных. ну и, как уже посоветовали, SSD :)

нарывался пару раз
в одном случае возникло из-за некорректного завершения работы базы, переносил индексы из одного tablespace в другой, кончилось место в xlog, база скрэшилась, после не стартовала, пришлось делать pg_xlogreset (или как там эта утилитка называется), индексы побились немного и ограничение уникальности не всегда стало срабатывать
а в другом случае обнаружил случайно, списал на какие-то изменения в минорных версиях postgresql, либо битые индексы

я делаю так, всё что пришло из API кладу во временную таблицу, а потом уже запросами обновляю/удаляю/вставляю. по мне так гораздо гибче и дешевле делать join в СУБД чем делать примерно то же самое множественными запросами на питоне. плюс в postgresql есть foreign data wrappers и можно из хранимки напрямую обращаться ко всяким api как к таблице минуя всякие питоны

по идее вам надо посмотреть все release notes на 9.1, 9.2, и 9.3, там написано про обратную совместимость, а вообще смотрите в ошибки которые высыпаются в экран.

подумайте еще раз нужен ли вам master-master и вообще нужна ли репликация при такой архитектуре.

1) Вам точно всегда нужны все строки запроса? Используйте сортировку и limit если нет
2) Вам точно нужны все поля из таблицы? Если нет, то есть смысл указать необходимые поля после select
3) Если postgresql >= 9.2 и нужно только одно поле из таблицы можно попробовать добавить его в индекс и добиться выполнения IndexOnlyScan
4) Если нет других запросов, или они не критичны, можно кластеризовать (CLUSTER) таблицу по этому индексу
5) ну и нет ничего зазорного в том чтобы первый запрос выполнялся не очень быстро, оптимизируйте размер таблицы и shared_buffers чтобы постараться уложить её в память.

кэшируйте на бакэнде, в мемкэше или еще где

я измеряю лаг в мегабайтах примерно так:

SELECT pg_xlog_location_diff(pg_last_xlog_receive_location(), pg_last_xlog_replay_location()) as bytes_lag