Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan - Mailing list pgsql-hackers

From Don Baccus
Subject Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
Date
Msg-id 3.0.1.32.20000820164957.014d2d60@mail.pacifier.com
Whole thread Raw
In response to Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
At 02:18 PM 8/20/00 -0400, Tom Lane wrote:

>However, that just shows that some patterns of usage of the function
>will yield unpredictable results.  I don't think that translates to an
>argument that the optimizer is allowed to make semantics-altering
>transformations...

Very much depends on the language spec, if such usage is "implementation
defined" you can do pretty much whatever you want.  Agressive optimizers
in traditional compilers take advantage of this.

In the case given, though, there's no particular reason why an application
can't grab "currval()" and then use the value returned in the subsequent
query.

On the other hand, heuristics like "if there's no nextval() in the
query, then currval() can be treated as a constant" are very common in
the traditional compiler world, too ...



- 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 by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: mac.c
Next
From: "Cray2"
Date:
Subject: Row Level Locking Problem