bubucha Сама таблица:
таблица tbl_test – 1822471 записей
вложенный селект возвращает 446 записей
сам запрос возвращает 4506 записей
индексы по id_object , enter и datetime

напрашивается либо составной индекс:
(enter,datetime[,idobject])
либо условный
(datetime[,idobject]) WHERE enter = 'T';

- в зависимости от прочей кухни. - Если всегда (за редкими исключениями) интересуемся только WHERE enter = 'T';, то условный - он поменьше должен быть. Если по разному - то составной.

При этом индекс просто по enter можно и прибить (сдается - он низкоселективен).
Да, и если никогда не фильтруем только по datetime, а всегда с условием по enter =...- то можно прибить и индекс просто по datetime.

bubucha Да, именно так и есть, при составном индексе datatime,idobject , все встает на свои места и пропадает необходимость помогать планировщику.

зы, посмотрев вот на это,
bubuchaЕсли WHERE a.datetime заменить на WHERE a.datetime +’0’ ,
то время выполнения функции становится нормальным (как и отдельного селекта)можно предположить, что по датам у вас в запросе селективность не большая (почти все записи (т.е. от ~20%) попадают в задаваемый диапазон дат, и запрет хранимке (+0) на использование именно этого индекса приводит ее в чувство).
тогда мое предположение о низкой селективности индекса по enter таки не верно. (т.к. общее действие фильтра довольно сильно, по вашим утверждениям усекает набор)
было бы понятнее, если бы был приведен результат EXPLAIN ANALYZE (для запроса, ес-но, а не для хранимки - бо последнее пока невозможно).
(таки напрашивается индекс именно по (enter,datetime[,idobject]), и именно в такой последовательности.



кстати, на чем пишем морду? (если на аксе - интересен способ раздачи прав по..., ибо акс с т.з. количества нерулимых коннектов - песня)

bubucha
Соответственно индексы стоят на всех полях, по которым либо отбор, либо join. (т.е. отдельные индексы по каждому полю, а не составные).1. использование 2-х индексов одной таблицы (одного ее вхождения) в одном запросе - дело затратное (а для пг еще и сравнительно новое - с 8.0), так, чтаа...
Если вы сами бегали по индексам (в том же аксе - Seek-ами), то должны представлять возможность оптимизатора поюзать тот или иной индекс при запросе с фильтрацией по нескольким полям.

если запросы распределены (по частоте) по фильтрам скажем так:
WHERE enter='что-нть' AND ....все что угодно - чаще всего
WHERE enter='что-нть' AND datetime Betwenn ... + все что угодно - тоже часто, или чуть пореже
... и т.п.
- то и индекс нужен по (enter,datetime[,]) - так как он будет в большинстве случаев использован и для тех и для других.
т.е. в случае 2-х полей два сложных индекса (перестановочные по полям) в общем случае предпочтительнее 2х индексов по каждому из полей. (надо смотреть по задаче).
конечно для большого числа полей это все не совсем так просто (т.к. число перестановок растет очень быстро, но все они и не нужны - есть типовые запросы задачи).
срубить индекс по object_id - плохо, т.к. он скорее всего у вас в FK, ПОсему нужно сделать хотя бы один индекс по (object_id[,]) - для быстрого джойна вашей записи к object-у, если понадобится.
Извините за назойливость


ЗЫ. я пока занимаюсь перелицовывание чисто мдб-ных прилад. Проблема в том, что мне нужна позаписное ограничение доступа (по текущей "роли", выбранной юзером, а не по юзеру), а акс сам открывает свои коннекты (если пользовать обычную его работу - т.е. слегка подновить старые прилады). Как-то ассоциировать юзера с выбранной им в _другом_коннекте_ ролью - затруднительно. А заставлять его помнить различные "ролевые" логины и пароли - имхо - извращение.
Т.ч. пока разделением ролевой видимости занимается прилада (она помнит выбранную роль). Но, думаю, это не совсем верно. (хотя по юзеру я и могу усечь видимость еще на сервере дополнительно сам - вьюхами)