В своей функции использую запрос

где $1 и $2 - параметры типа date. Для некторого набора параметров функция выполняется 7 секунд. Если же в запросе 
заменить эти параметры на конкретные даты (такие же как и в вызове функции), то функция возвращает те же данные за полсекунды.
Подскажите плиз, как решить проблему скорости выпонения с параметрами!

Скорее всего оптимизатор PostgreSQL решил что селективность индекса по date низкая и решил его не использовать. Учитывая что у PostgreSQL нет хинтов, даже не знаю как заставить его использовать индекс.

Для меня - новость  

Нагуглил такую мантру:

Надеюсь это на уровне сессии ставится и не требует особых привилегий.

1) Да, на уровне сэссии. 
2) Да привилегий не требует.
3) В сложных запросах, где seqscan таки нужэн -- это проблема.

Точно сработает EXECUTE 'SELECT ... WHERE table_name.date BETWEEN ' || quote_ident($1) ||' AND '|| quote_ident($2)'

Вполне вероятно, что сработает просто подставлять во все места полный SELECT с именами переменных, без placholderов.

А как у PG обстоят дела с хардпарсом запросов? У оракла с этим прямтаки беда. Для построения плана требуется великое множество глобальных локов, потому всех новичков, которые пытаются применять подобные решнеия (без дейсвтитеьной надобности на то),  больно бьют линейкой по рукам

Включение в текст функции строчки:

Полностью решило проблему.
Спасибо-преспасибо огромное

Denis, было бы неплохо в конце процедуры вернуть этот флаг в исходное состояние. 

ОК, спс

Да нормально у pg с парсом запросов. Оно занимает процэссорное время (ну, составление плана, в первую очередь, да и то у простых запросов там особо ничего не делается) -- но к plan cache, я так понимаю, оно обращается всего два раза. Ниразу не слышал, чтобы составление планов отняло через чур много ресурсов.

спасибо, возьму на заметку.

Ситуация с оркалом примерно такова: Как я уже говорил, построение плана, при хардпарсе, требует большого количества блокировок на словари. Соответственно, если много сессий начинают одновременно хардпарсить, они начинают толкаться на этих блокировках и производительность всей системы существенно падает. Чтобы минимизировать эти издержки, оракл хранит уже сформированные планы запросов в т.н. shared pool, и в случае повторного выполнения запроса, хардпарс уже не происходит, лишь софпарс, не требующий такого же количества блокировок. Идентичность запросов оракл сопоставляет по тексту самого запроса. Соответственно, если появляется сессия, которая начинает генерить 100500 уникальных запросов в секудну отличие которых лишь в  "where val = 1", " where val = 2", Shared pool резво переполняется, из него вытесняются прочие запросы, соответственно все прочие приложения, которые в этот же момент работают с базой начинают харпарсить, толкаться на блокировках, все встает колом. 

Сам я тоже такого не видал, лишь читал о таком.   

Есесно есть и от этого пилюля, в результате применения которой оракл вышеописанные запросы начинает приводить к виду "where val = :b1", но ее наличие все равно не повод не дать лишний раз новичку линейкой по рукам.  

Я это все пишу лишь для того, чтобы было понятно чего я опасаюсь. /*и в тайне подпитываю надежду, что в ПГ такого беспорядка таки нет*/