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

Tom Lane wrote:
>
> =?iso-8859-1?Q?Tiago_Ant=E3o?= <tra(at)fct(dot)unl(dot)pt> writes:
> > Isn't the problem more general than just nextval?
>
> Yes it is, and that's why I'm not very excited about the idea of
> adding special-case logic for nextval/currval into the optimizer.
>
> It's fairly easy to get around this problem in plpgsql,

it is, once you know that psql implements volatile currval ;)

> eg
>
> declare x int;
> begin
> x := currval('seq');
> return f1 from foo where seqfld = x;
>
> so I really am going to resist suggestions that the optimizer should
> make invalid assumptions about currval by itself ...

Why is assuming a constant currval any more "invalid" than not doing so ?

As the execution order of functions is undefined, can't we safely state that
all
currval's are evaluated first, before any other functions that could change
its return value ?

currval is not like random which changes its value without any external
reason.

Afaik, assuming it to return a constant within a single query is at least as
correct as not doing so, only more predictable.

----------------
Hannu