Ещё можно делать так:

SELECT id FROM table WHERE id > последний_прочитанный_в_прошлый_раз_id ORDER BY(id) LIMIT N

Тогда при сканировании по индексу не придется каждый раз пропускать кучу записей, а можно будет начать сразу с нужного места.

У разработчиков, к сожалению, нет возможности проверять деградацию производительности на всех возможных ОС и конфигурациях оборудования. В среднем, постгрес становится только быстрее. Но на отдельных системах он может становиться медленнее.
Вы могли бы помочь сообществу, если бы нашли с помощью git bisect конкретный commit, который привёл к замедлению на вашей системе. Результаты можно отписать в pgsql-hackers mailing list. Без внимания они не останутся.

Официального словаря синонимов действительно нет, но можно использовать hunspell. Специально для упрощения установки и конфигурирования hunspell, мы сделали расширение на github.
https://github.com/postgrespro/hunspell_dicts

Из средств, поддерживающих master-master мне известны PGCluster, Bucardo, rubyrep, Postgres-XC. PGCluster и rubyrep давно не поддерживаются. Postgres-XC — перспективный проект, но не смотря на то, что грозится зарелизится, всё ещё сырой. Наиболее прилично выглядит Bucardo, хотя не приходилось им пользоваться. Надо также иметь ввиду, что он асинхронный.

Я работаю над похожей задачей: индексный поиск по регулярным выражениям в БД. Можно вот тут почитать и презентацию посмотреть:
www.pgcon.org/2012/schedule/events/383.en.html
В применении к вашему случаю алгоритм будет такой:
1. Залить N текстов в БД.
2. Построить индекс.
3. Искать по индексу M раз.
Было интересно посмотреть, какие у вас тексты и выражения, насколько применим к этой задаче мой подход.