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

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
Date: 2000-08-20 23:49:57
Message-ID: 3.0.1.32.20000820164957.014d2d60@mail.pacifier.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Don Baccus 2000-08-21 00:31:03 Re: Row Level Locking Problem
Previous Message Hannu Krosing 2000-08-20 23:27:54 Re: Optimisation deficiency: currval('seq')-->seqscan, constant-->index scan