Как обходят в Pg необходимость использования кластерных индексов?

Здравствуйте

Ситуация следующая: есть база, в которой основная нагрузка приходится на селекты, причем в основном выборка идет по одному полю (что то вроде select * from table1 where table1.name = 'vasya'). Исходя из моего опыта в MS SQL, тут было бы неплохо иметь кластерный индекс, включающий в себя поле table1.name, но в Pg их нет.

Собственно и вопрос: как решают в Pg необходимость выгрузки последовательно идущих записей по какому либо признаку?

Arm79,
создают руками)))
Сейчас можно матвьюху с упорядоченным набором и индексами.

Arm79,
Ещё можно саму таблицу упорядочить по какому-нибудь индексу,
только не частичному.

Arm79,
Кстати, в первом случае создаётся подобие оракловых табличных кластеров
во втором случае - таблица просто упорядочивается по индексу.

ОКТОГЕН
создают руками)))

Не, руками я видел, но таблицу в 50 млн записей ставить на ручной CLUSTER - это как то неправильно

Да и материализованные представления, если верно, что я прочитал, обновляются только после ручного Refresh, и с эксклюзивной блокировкой.

Оба варианта долгие, и требуют внешних шедулеров. Не подходит.

Arm79,
Всё-таки одиночная таблицы, упорядоченная на диске по индексу?
Тады лехко.
Скажите ему вот это заклинание:

CREATE INDEX index_name ON tablename   USING btree (expr);
ALTER TABLE tablename CLUSTER ON index_name;

Не забывать периодически говорить

CLUSTER TABLE tablename;

Arm79,

Если заменить `SELECT *` на более конкретный `SELECT name, age, gender`, то можно сделать
покрывающий индекс `ON table1(name,age,gender)`.

В целом же, тот факт что в MS SQL это принято значения не имеет. Разные СУБД, разные подходы, разные практики.
Я бы не мудрил и просто сделал индекс `ON table1(name)`, а дальше уже смотрел бы на поведение базы и запросов.

Arm79
ОКТОГЕН создают руками))) Не, руками я видел, но таблицу в 50 млн записей ставить на ручной CLUSTER - это как то неправильно Да и материализованные представления, если верно, что я прочитал, обновляются только после ручного Refresh, и с эксклюзивной блокировкой. Оба варианта долгие, и требуют внешних шедулеров. Не подходит.

9.4 эксклюзивно не блочит.
Без внешнего шедулера в postgresql делать нечего.

Arm79

Здравствуйте Ситуация следующая: есть база, в которой основная нагрузка приходится на селекты, причем в основном выборка идет по одному полю (что то вроде select * from table1 where table1.name = 'vasya'). Исходя из моего опыта в MS SQL, тут было бы неплохо иметь кластерный индекс, включающий в себя поле table1.name, но в Pg их нет. Собственно и вопрос: как решают в Pg необходимость выгрузки последовательно идущих записей по какому либо признаку?

если .name - primary key то от кластерного индекса будет пользы мало.

PS: ssd снижает необходимость в кластерных индексах весьма сильно.

--
Maxim Boguk
www.postgresql-consulting.ru

ОКТОГЕН
Всё-таки одиночная таблицы, упорядоченная на диске по индексу?

Да.

vyegorov
то можно сделать покрывающий индекс `ON table1(name,age,gender)`.

Это я в курсе :-)

vyegorov
В целом же, тот факт что в MS SQL это принято значения не имеет. Разные СУБД, разные подходы, разные практики.

Так и я про то же. Спросил про те практики, которые применяются в Pg в тех случаях, когда в аналогичных в MS SQL юзают кластерные индексы.

ОКТОГЕН
Без внешнего шедулера в postgresql делать нечего.

Я тоже так подумал. Придется ставить на периодический ребилд индекса, архивацию и т.п. Хорошо, хоть автовакуум есть

Вообще много непонятного пока в Pg. Разбираюсь по чуть-чуть...

PS Спасибо за помощь.