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

Tom Lane wrote:
> 
> Tiago Antão <tra@fct.unl.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