Цитата(LSD @ 30.1.2012, 11:26  ) |
| у PostgreSQL нет хинтов |
Для меня - новость
Нагуглил такую мантру:
| Код |
|
Надеюсь это на уровне сессии ставится и не требует особых привилегий.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PostgreSQL > медленный select в пользовательской функции |
| Автор: Denis 29.1.2012, 23:09 | ||
В своей функции использую запрос
где $1 и $2 - параметры типа date. Для некторого набора параметров функция выполняется 7 секунд. Если же в запросе заменить эти параметры на конкретные даты (такие же как и в вызове функции), то функция возвращает те же данные за полсекунды. Подскажите плиз, как решить проблему скорости выпонения с параметрами! |
| Автор: LSD 30.1.2012, 11:26 |
| Скорее всего оптимизатор PostgreSQL решил что селективность индекса по date низкая и решил его не использовать. Учитывая что у PostgreSQL нет хинтов, даже не знаю как заставить его использовать индекс. |
| Автор: Zloxa 30.1.2012, 13:34 | ||||
Для меня - новость Нагуглил такую мантру:
Надеюсь это на уровне сессии ставится и не требует особых привилегий. |
| Автор: tzirechnoy 30.1.2012, 15:27 |
| 1) Да, на уровне сэссии. 2) Да привилегий не требует. 3) В сложных запросах, где seqscan таки нужэн -- это проблема. Точно сработает EXECUTE 'SELECT ... WHERE table_name.date BETWEEN ' || quote_ident($1) ||' AND '|| quote_ident($2)' Вполне вероятно, что сработает просто подставлять во все места полный SELECT с именами переменных, без placholderов. |
| Автор: Zloxa 30.1.2012, 17:02 | ||
А как у PG обстоят дела с хардпарсом запросов? У оракла с этим прямтаки беда. Для построения плана требуется великое множество глобальных локов, потому всех новичков, которые пытаются применять подобные решнеия (без дейсвтитеьной надобности на то), больно бьют линейкой по рукам |
| Автор: Denis 30.1.2012, 17:19 | ||
Включение в текст функции строчки:
Полностью решило проблему. Спасибо-преспасибо огромное  |
| Автор: Zloxa 30.1.2012, 17:21 |
| Denis, было бы неплохо в конце процедуры вернуть этот флаг в исходное состояние. |
| Автор: Denis 30.1.2012, 17:32 |
| ОК, спс |
| Автор: tzirechnoy 30.1.2012, 17:41 |
| Да нормально у pg с парсом запросов. Оно занимает процэссорное время (ну, составление плана, в первую очередь, да и то у простых запросов там особо ничего не делается) -- но к plan cache, я так понимаю, оно обращается всего два раза. Ниразу не слышал, чтобы составление планов отняло через чур много ресурсов. |
| Автор: Zloxa 30.1.2012, 19:22 | ||
спасибо, возьму на заметку. Ситуация с оркалом примерно такова: Как я уже говорил, построение плана, при хардпарсе, требует большого количества блокировок на словари. Соответственно, если много сессий начинают одновременно хардпарсить, они начинают толкаться на этих блокировках и производительность всей системы существенно падает. Чтобы минимизировать эти издержки, оракл хранит уже сформированные планы запросов в т.н. shared pool, и в случае повторного выполнения запроса, хардпарс уже не происходит, лишь софпарс, не требующий такого же количества блокировок. Идентичность запросов оракл сопоставляет по тексту самого запроса. Соответственно, если появляется сессия, которая начинает генерить 100500 уникальных запросов в секудну отличие которых лишь в "where val = 1", " where val = 2", Shared pool резво переполняется, из него вытесняются прочие запросы, соответственно все прочие приложения, которые в этот же момент работают с базой начинают харпарсить, толкаться на блокировках, все встает колом. Сам я тоже такого не видал, лишь читал о таком.  Есесно есть и от этого пилюля, в результате применения которой оракл вышеописанные запросы начинает приводить к виду "where val = :b1", но ее наличие все равно не повод не дать лишний раз новичку линейкой по рукам.  Я это все пишу лишь для того, чтобы было понятно чего я опасаюсь. /*и в тайне подпитываю надежду, что в ПГ такого беспорядка таки нет*/ |