Re: Why Stored Procedure is Slower In The Following Case?
В списке pgsql-general по дате отправления:
| От | A. Kretschmer |
|---|---|
| Тема | Re: Why Stored Procedure is Slower In The Following Case? |
| Дата | |
| Msg-id | 20100120072209.GA21597@a-kretschmer.de обсуждение исходный текст |
| Ответ на | Why Stored Procedure is Slower In The Following Case? (Yan Cheng Cheok <yccheok@yahoo.com>) |
| Список | pgsql-general |
In response to Yan Cheng Cheok : > As you can see, their select statement is the same. Except stored > procedure is having additional 'QUERY'. Does that make the speed > difference? No. The problem is, the planner don't know the actual parameters. Therefore the planner picked out a wrong plan (seq-scan instead of index-scan). You can avoid this by rewrite your function: use a dynamic query, use EXECUTE. Read more: http://www.postgresql.org/docs/8.4/interactive/plpgsql-control-structures.html Chapter 38.6.1.2. RETURN NEXT and RETURN QUERY Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header) GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431 2EB0 389D 1DC2 3172 0C99
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера