| От | Tom Lane |
|---|---|
| Тема | Re: query planning different in plpgsql? |
| Дата | |
| Msg-id | 11906.1256314818@sss.pgh.pa.us обсуждение |
| Ответ на | Re: query planning different in plpgsql? (Scott Mead <scott.lists@enterprisedb.com>) |
| Список | pgsql-performance |
On Fri, Oct 23, 2009 at 11:38 AM, Michal J. Kubski <michal.kubski@cdt.pl>wrote:
>> I am running the following one and it takes 10 minutes in the procedure
>> when it is pretty fast standalone.
>>
>> # EXPLAIN ANALYZE SELECT m.domain_id, nsr_id FROM nsr_meta m, last_snapshot
>> l WHERE m.domain_id = l.domain_id;
Is it *really* just like that inside the stored procedure? Usually
the reason for a difference in plan is that the procedure's query
references some variables of the procedure, which people think act
like constants but they don't.
Also, if you're executing the SELECT as a plpgsql FOR-loop, it will be
planned like a cursor, so the thing to compare against is
explain [analyze] declare x cursor for select ...
regards, tom lane
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера