Извините, случайно запостил недописанное сообщение. Повторяюсь.
Переносим БД из MSSQL. С PostgreSQL недавно начал работать, причём наскоком, толком и изучать некогда было. До сих пор достаточно успешно боролся с возникающими препятствиями, но сейчас поставлен в тупик.
Есть две таблицы (упрощу для наглядности, но ключи и связи такие же):
и есть запрос:
- для каждой строки из родительской t1 найти минимум и максимум из дочерней t2.
Сейчас в этих таблицах щедящие тестовые данные - в родительской 300, в дочерней 12000000. Записи дочерней почти равномерно распределены между родительскими.
В MSSQL никогда с этим кодом проблем не было при любом обёме данных - для каждой родительской строки по два перехода по индексу к крайним значениям второго поля справа и слева. Времени практически не занимает-миллисекуды.
В PostgreSQL идёт долгое и нудное сканирование индекса на основе ограничения уникальности - 2 раза. Времени - две минуты на свежайших статистиках. А чуть погодя - до двадцати минут. Ни в какие ворота не лезет.
Я уже и так и эдак.. Различные комбинации индексов, различные варианты запросов пробывал. Кто-нибудь значет, что тут можно подкрутить?

Конечно же я так пробывал - ещё дольше работает.

to Vladimir Sitnikov >> MSSQL тоже преобразует min() и max() в top 1 с одной и с другой стороны. Но делает это элегантно - сразу берёт по одной записи индекса. Postgres же, при использовании min() и max() просто сканирует индекс, а при использовании order by .. limit 1/ order by .. desc limit 1 выдаёт совсем уж грустный план - сперва выбирает всё, потом сортирует, потом берёт верхнюю строку.. :-(

Может индекс какой хитрый построить?

Да, забыл сказать, у меня "Линтер-ВС" - СУБД на основе PostgreSQL 7.4.

to 4321ё >> Явные индексы тоже создавал, и составные, и по-отдельности - не помогает. Только вот с минусом не пробывал - щас проверил, так PostgreSQL использует для обоих сортировок, и в одну, и в другую сторону, индекс, который с минусом :-)
Ничего не понимаю..
В планах индекс по ограничению уникальности используется, как и явные индексы, когда они есть, но присходит для каждой строки родительской таблицы сканирование всех записей по условию связывания.
То есть в конечном итоге сканируется все 12000000 записей, по два раза, и то не за один проход.
Вот план для варианта только с ограничениями уникальности, и при использовании min/max (в плане тоже подправил имена объектов, чтобы похоже было на пример):

Кувалдин Роман
Тогда вопросы к Линтеру - что они внутри накосячили такого, что индексы не работают.
П.С. Кстати, не все линтеры сделаны на базе Постгреса. Об этом даже на данном форуме писали.
Самому интересно, почему так туго с индексами. А другой Линтер тоже пользовали, тот вообще - обнять и плакать..

По всему видно, что коллеги, высказывающие опасения по поводу причастности "моего Линтера" к PostgreSQL, в глаза не видели "не-Postgre-Линтер". Сразу оговорюсь - речь идёт о "Линтер-ВС" 6.0. Напутать что либо здесь невозможно - есть два Линтера-ВС, и они абсолютно разные - не перепутаешь, хотя даже цифры одинаковые!
Так вот "мой Линтер" запускается командой service postgresql start :-)
Первая, если можно так сказать, версия СУБД Линтер-ВС (Вооружённые Силы) была разработана в годах 2003-2004 ЗАО НПП "РЕЛЭКС", на базе Линтер 5.7, в Министерство Обороны поставлялась от имени ВНИИНС (НПО, институт, фирма?? -не помню). Затем году в 2004-2005 произошла подмена этой СУБД на совершенно другую, разработаную в самой ВНИИНС на базе PostgreSQL 7.4.
pavelvp - разработчик того, первого Линтера-ВС. Здравствуйте, pavelvp.
Тот топик, на который нас отправляет Кувалдин Роман -
Кувалдин Роман
Слова разработчика

Кстати, по поводу ЛИНТЕР-а рекомендую обратиться прямо к pavelvp инициирован мною же, в далёком 2004. Тогда отмазаться от перехода с MSSQL на Линтер удалось, сейчас же пришло время вернуть долги, но переходом уже на новый Линтер-ВС.
pavelvp, плакать нам тогда пришлось от осознания, какой же объём работы предстояло бы выполнить при миграции с SQL Server 2000, и ещё не известно, получилось ли бы. У Вас замечательный продукт, но очень специфичен. Я уже не помню всех тонкостей, но помню неподдельную радость в глазах и чуство, что теперь-то горы свернём, когда нам принесли "новую версию" Линтера-ВС, по сути - Постгрес. С ним тоже немало заморочек, но всё решаемо.
P.S. С проблемой, давшей начало данному разговору, я решил не заморачиваться. При выборе от одной (что чаще всего), до пары десятков строк из родительской таблицы, время доступа приемлемое. А когда нужно всё прочитать (что тоже не редкость) - придётся ждать, что ж делать - пока ничего не помогло, а дальше время тратить - непозволительная роскошь.