Александр Коротков

Вот такой запрос выведет список имен таблиц (а также имен схем, где они расположены) для текущей БД.

SELECT n.nspname, c.relname
FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'r' AND n.nspname NOT IN('pg_catalog', 'information_schema');

Посмотреть список таблиц другой БД (не той, к которой подключен) – нельзя. Нужно подключаться к каждой БД отдельно.

Чтобы мог использоваться быстрый поиск ближайших соседей (KNN GiST), делайте ORDER BY по выражению

geometry <-> ST_SetSRID(ST_POINT(37.72308, 55.47957), 4326)

Нужен PostgreSQL 9.5+, PostGIS 2.2+

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

Я не совсем понял, что именно нужно сделать. Но, я думаю, вам нужно в сторону WINDOW FUNCTIONS поглядеть.

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

В PostgreSQL можно использовать расширение hstore или, начиная с 9.4, тип jsonb (json с эффективным бинарным хранением).

Посмотрите в сторону расширения hstore.

Вполне возможно. По-сути нужно просто постгрес вручную поставить. Шаги такие:
1) Поставить Visual C++ Redistributable нужной версии
2) Скопировать файлы самого постгреса
3) Сделать initdb
4) Запустить базу через pg_ctl (или создать сервис через pg_ctl)

В 9.4 будет поддерживаться, закомичено в master ветку
git.postgresql.org/gitweb/?p=postgresql.git;a=comm...
А задачу

Связано это с тем, что если юзер накосячит в основной базе можно было накатить бэкап на состояние "было 30 мин назад", так как изменения в БД происходят достаточно часто, а накатывать суточный бэкап будет очень болезненно, так как потеряется куча данных.

сейчас обычно решают с помощью PITR.

1) Правильно пишется SP-GiST и GiST.
2) cube поддерживает GiST индексы
www.postgresql.org/docs/9.2/static/cube.html
но поиск по расстоянию не поддерживает (можно делать поиск на вхождение в прямоугольную область, а потом доп. фильтрацию). Реализовать не проблема, никому не было достаточно сильно это нужно. SP-GiST для cube тоже пока не реализовали.
3) В целом, если есть опыт программирование на C и желание разобраться, то всё можно сделать.

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

Ещё, как вариант, написать макрос для LibreOffice/OpenOffice, который будет делать конвертацию со всеми необходимыми преобразованиями. Вот есть топик по переводу xls в csv
www.oooforum.org/forum/viewtopic.phtml?t=52942
можно сделать и обратно.

Советую также посмотреть поиск ближайших соседей в GiST индексах PostgreSQL начиная с версии 9.1. Там всё сделано куда более естественно с точки зрения пользователя.
А вообще если точки очень часто перемещаются по карте, то я бы посоветовал не пользоваться функциями СУБД, а просто построить какой-нибудь Quad-tree в памяти и искать по нему.

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

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

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

Можно через массивы сделать:

SELECT
	"deviceId"
FROM
	devices_categories
GROUP BY
	"deviceId"
HAVING
	array_agg("catId") @> (
		SELECT
			array_agg("categoryId")
		FROM
			object_categories
		WHERE "objectId" = $1);

Кроме этого, если сделать вместо (или в дополнение к) devices_categories массив catIds в таблице device'ов, то можно будет построить по нему GIN индекс и такой запрос будет очень быстро выполняться.

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

Это, видимо, разновидность атаки, когда скрипту на вход посылаются такие данные, которые при разборе параметров или дальнейшей обработке образуют много коллизий хеш-функции. В результате массивы, содержащие эти данные, начинают работать ужасно медленно. Т.е. получается это разновидность DoS атаки. Почему это грозит PHP именно до версии 5.3.9, не знаю. Возможно, там использовалась простая хеш-функция, к которой легко подобрать коллизии.