Alexey Lesovsky

выдача результата при первом запросе упирается в скорость чтения c диска, размер индекса и т.н index bloat.
покажите (из psql):
1) \di+ index_table_on_field
2) select * from pgstattuple('index_table_on_field')
3) и вкратце пару слов о дисковой подсистеме (наличие контроллера?, тип дисков, средняя нагрузка по sar -d)

гугл сходу выдает кучу ссылок на всякие инструменты. пробуйте и наверняка чтото подойдет.

p.s. в свое время искал аналогичный инструмент для конвертации mysql в postgres. на все поиски и эксперименты ушло чуть больше часа.

да, любопытное поведение...
попробуйте сделать так

CREATE OR REPLACE VIEW rastitelnos_line_10000 AS 
 SELECT *
   FROM rastitelnos_line
  WHERE rastitelnos_line.objectkey NOT IN ('L0071131000','L0071131100','L0071224000') OR rastitelnos_line.objectkey IS NULL;

вот ответ от более опытных коллег (я еще сам учусь))):
конкретно тот запрос не ускоряется ни как... проблему при order by снимать через WITH или offset 0 в подзапросе и только после накладыванием сортировки.
т.е. там сама постановка задачи с 1.4M строк в сортировке и 10k строк на выходе - не рабочая

вот как-то так, совсем безрадостно ((

еще есть PgBarman но без амазона из-каропки

select now() - pg_last_xact_replay_timestamp();
запустите на стендбaе через psql, получите лаг в секундах.

покажите pg_hba.conf
скорей всего вы локально подключаетесь по unix-сокету, а phppgadmin по ipv4 сокету.

к этому нужно еще добавить TEMPLATE = template0.

т.е. получится

CREATE DATABASE "имя_базы"
  WITH OWNER "postgres"
  ENCODING 'UTF8'
  LC_COLLATE = 'ru_RU.UTF-8'
  LC_CTYPE = 'ru_RU.UTF-8'
  TEMPLATE = template0;

эм, а что подразумевается под диск мерждем?

навскидку... включите track_io_timing и смотрите вьюхи pg_statio_user_tables, pg_statio_user_indexes (поля blks_read/blks_hit).

Сколько у вас коннектов если CPU под 100%
если больше чем число ядер на сервере, ставьте pgbouncer и работайте через него.

используйте pgbadger для выявления медленных запросов, затем оптимизируйте их.

И остается открытым вопрос дисковой нагрузки, запустите iostat -x 5, если util% доходит до 100% то пишите, выдам еще пачку советов...

# grep -vE "^#|^$" pg_hba.conf 
local   all             all                                     peer map=mymap
# grep -vE "^#|^$" pg_ident.conf 
mymap           lesovsky                postgres
$ whoami
lesovsky
$ psql -U postgres
psql (9.3.4)
Type "help" for help.
postgres=#

для репликации бд используйте нативную streaming replication, она довольна проста в освоении.
www.thislinux.org/2014/03/postgresql-streaming-rep...

Repmgr по сути набор скриптов над потоковой репликацией, поэтому с ними можно добиться того же результата.

Best practices следующие:
1. железо стендбая должно быть идентично или лучше чем у мастера, т.к. стендбай может в случае аварии стать мастером и будет грустно если он не потянет нагрузку.
2. обратите внимание на надежность и пропускную способность сети, она должна переваривать те объемы трафика что полетят с мастера на стендбай
3. оттестируйте и составьте инструкции по переключению стендбая в мастер, чтобы в случае аварии не суетиться (оттестировать можно на staging).
4. настройте wal archiving и резервное копирование через basebackup т.к. при потенциальных ошибках оператора/кривой миграции (DROP/TRUNCATE TABLE, DELETE ALL) все изменения улетят на стендбай и он вместе с мастером превратится в тыкву.

их тех «косяков» что я обнаружил:
— в режиме балансировки, при падении слейва, pgpool может начать игнорировать мастера))) в итоге мастер хоть и жив, но pgpool не отправляет на него запросы; толи это странность в health_ и sr_ проверках, толи еще что…
— неэффективный пуллинг конектов, нельзя запихнуть в него больше клиентов чем max_connections в postgresql.conf (в pgbouncer же это можно сделать); т.е. пуллинг он как бы есть но внутри одного воркера =)
— непонял как подцепить pgpool к постгресу через unix-сокет, не видит его и все тут… собака, вроде все тривиально решается одной строчкой конфига, но нет жэ… all backends are down
— все время пытается мне сделать при сбое слейва авто-файловер,… ну не сторонник я автоматики при разгребании аварии с базами данных…

пока заставил его работать как мне надо, но какой ценой… помоему keepalived+haproxy+pgbouncer и какая-нибудь makara на строне приложения были бы годнее

вот тоже приличный инструмент

итак новые данные
1. WAL нужно отселять на соседний физ.диск/рэйд
2. время выполнения нужно больше
3. iostat? нужен ли и в каком виде его собирать, портянку накопленную на несколько часов работы теста еще нужно как-то проанализировать

Стоит ли выкладывать результаты когда все закончится?