Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan

Поиск
Список
Период
Сортировка
От Don Baccus
Тема Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
Дата
Msg-id 3.0.1.32.20000820104844.014ceb40@mail.pacifier.com
обсуждение исходный текст
Ответ на Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
At 01:25 PM 8/20/00 -0400, Tom Lane wrote:

>However, even if we had a concept of "constant within a transaction/
>scan/whatever", currval() would not qualify --- what if there is a
>nextval() being invoked somewhere else in the query, possibly inside a
>user-defined function where the optimizer has no chance of seeing it?
>
>In short, there is no way of optimizing currval() in the way you want
>without risking breakage.

Does Postgres guarantee order of execution of functions?  Many languages
don't other than to follow precedence rules, which is why functions with
side-effects (such as nextval) can yield "implementation defined" or
whatever results.  

My point is that such queries may not yield predictable results.  Perhaps
today due to left-right execution order or the like, but do you want to
guarantee a defined order of execution in the future?



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tiago Antão
Дата:
Сообщение: Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan