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

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

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

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

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

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

ОКТОГЕНВсё-таки одиночная таблицы, упорядоченная на диске по индексу?
Да.
vyegorovто можно сделать
покрывающий индекс `ON table1(name,age,gender)`.
Это я в курсе :-)
vyegorovВ целом же, тот факт что в MS SQL это принято значения не имеет. Разные СУБД, разные подходы, разные практики.
Так и я про то же. Спросил про те практики, которые применяются в Pg в тех случаях, когда в аналогичных в MS SQL юзают кластерные индексы.
ОКТОГЕНБез внешнего шедулера в postgresql делать нечего.
Я тоже так подумал. Придется ставить на периодический ребилд индекса, архивацию и т.п. Хорошо, хоть автовакуум есть

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

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

Maxim Bogukесли .name - primary key то от кластерного индекса будет пользы мало.
Чавой это? Если в таблице 50 млн записей, и мне нужно извлечь все записи, относящиеся к определенному пользователю количеством от 30 до 50 000. Так что польза будет.

в реальности структура примерно такая:
id bigint identity(1,1) primary key,
name varchar,
куча других полей

в ms sql индекс был бы интересен такой:
create clustered index ix_name on table1(name, id)

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

В принципе, можно дальше тему про кластерные индексы не поднимать, понятно, что в текущей версии такого нет.

qwwqстранно, что партицировать вдоль name никто пока не предложил.
нет смысла, там один диск RAID 1+0

qwwqверсии, карл.
версии
версии записей, карл
причем здесь версии?

ОКТОГЕНArm79,
Тут проскакивало предложение сделать покрывающий индекс.
В pg есть такая штука как index only scan.
Если 50 КК записей малоинтенсивно обновляются(тогда выборка чаще попадает на блоки с флагом видимости true),
то большая вероятность, что если указать имена полей в SELECT - то будет выбран план
при котором сканироваться будет только индекс, и инфа будет браться только оттуда.
Как и в oracle, это быстрая штука и никакого кластера не надо, только REINDEX периодический.
Ясно, но нет, таблицы будут обновляться достаточно часто.

В принципе, я пока склоняюсь к следующему:

1) Партиционировать нужную таблицу на 10 частей (исключительно с целью разнести операции архивирования и ребилда индексов).
2) периодически (предположительно, раз в неделю, архивировать, делать CLUSTER, а потом ребилдить индексы

Нужно еще продумать, как осуществлять репликацию с такой схемой.

Ну или отказаться от Pg :-) В пользу MySql. Заказчик не хочет платить за лицензии мелкомягким. Не могу сказать, что я его осуждаю.

Arm791) Партиционировать нужную таблицу на 10 частей (исключительно с целью разнести операции архивирования и ребилда индексов).
Кстати, эксперты, не подскажете, а если кластеризировать одну партицию, селекты по мастер-таблице по прежнему работать будут, если выборка физически будет в другой партиции?

PgSQLAnonymousТавой это. Вам же сказали: primary key , т.е. записей по нему может быть от 0 до 1. ;)
А, точно :-) Не посмотрел про primary, держал в уме реальную структуру, с суррогатным ключом :-)

ОКТОГЕН,

Спасибо, ушел читать. Про foreign key - неприятный сюрприз, буду смотреть. Разбиение планировал по id - остаток от деления на 10.