Это тоже мало о чём говорит, т.к. количество столбцов и их тип на это сильно влияют. Но это не важно вообще. Попробуйте создавать индекс с CONCURRENTLY - должно быть сильно быстрее (удалять его тоже надо с CONCURRENTLY). Но вообще проводить эксперименты с созданием индексов на проде я бы не советовал. Надо создать облегчённый дамп (но с таким количеством записей, чтобы планировщик отдавал предпочтение использованию индекса, а не фулскану таблицы).

Тогда зачем столько данных в ней?

> удалять его тоже надо с CONCURRENTLY
Че?

> удалять его тоже надо с CONCURRENTLY
Че?

Ух ты, и правда такая опция есть.

Оно и так заблокирует.
> With this option, the command instead waits until conflicting transactions have completed.

DROP INDEX и так работает примерно моментально.

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

Здравствуйте. Составляю индекс таблицы. Так как таблица очень большая, создать на ней индекс и проверить как планировщик на него отреагирует весьма долго.

Можно ли как то использовать планировщик с индексом, который я только собираюсь?

В случае с вызовом хранимой процедуры это вообще невозможно реализовать

Умеет. А ругают в т.ч. потому, что с ним очень легко "выстрелить себе в ногу".

а ткнуть носом где про это можно? про выстрел в ногу это то понятно, это можно и при репликации сделать.

по умолчанию индекс в pg строится по asc или по desc?

Так вот тут: https://www.pgpool.net/docs/latest/en/html/intro-whatis.html написано: "Load Balancing" (ограничения указаны тут: https://www.pgpool.net/docs/latest/en/html/restrictions.html ).

А вот подробное описание, с примерами: https://www.pgpool.net/docs/latest/en/html/runtime-config-load-balancing.html

ASC

у меня почему-то стал долго отрабатывать дефолтный индекс по asc зато быстро по desc в чем может быть причина?

Что такое "долго отрабатывать"?