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

Hannu Krosing <hannu(at)tm(dot)ee> writes:
> Could we add an additional function with strictly defined behaviour of
> returning the value of a sequence at the beginning of current query, perhaps
> called ccurval()

Not unless you want the system to run around and read the current value
of *every* sequence object at the start of *every* transaction, as
insurance against the possibility that some bit of code might ask for
the value of ccurval('foo') at some point in the transaction.

This state-saving could doubtless be optimized away to some extent,
but quite frankly I don't feel a strong need to work on it. You haven't
yet presented any compelling reason why we should care deeply about the
performance of WHERE bar = currval('foo') --- how many people want to do
that? Even more to the point, why is this so important that we should
care about making it fast with absolutely no help from the user? I have
a hard time accepting an "I won't use plpgsql" argument. There are many
more pressing performance problems on my to-do list, most of them with
no such easy workaround.

regards, tom lane