Re: key = currval('tab_key_seq') choses SEQSCAN?! - Mailing list pgsql-general

From Greg Stark
Subject Re: key = currval('tab_key_seq') choses SEQSCAN?!
Date
Msg-id 87u11dha9u.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: key = currval('tab_key_seq') choses SEQSCAN?!  (Joe Conway <mail@joeconway.com>)
Responses Re: key = currval('tab_key_seq') choses SEQSCAN?!  (Eric Ridge <ebr@tcdi.com>)
Re: key = currval('tab_key_seq') choses SEQSCAN?!  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Joe Conway <mail@joeconway.com> writes:

> Eric B. Ridge wrote:
> > gotcha.  Stated differently, it's not volatile because, by design, it doesn't
> > always produce the same output for the same input.
>
> Right. But further, it doesn't even produce the same result within a single
> scan. Here's from pg_proc.h:

Consider a query like

select * from foo where a = currval('xyz') and b = nextval('xyz')

in that case it wouldn't be legitimate to use an index lookup on "a". Imagine
if currval('xyz')==3 at the start and there are multiple records where a=3.
Then it would return records where b = 3,4,5,... as long as a=3, which doesn't
really make sense.

Though actually I don't really see how any interpretation of this query really
makes a whole lot of sense.

--
greg

pgsql-general by date:

Previous
From: "Jeffrey W. Baker"
Date:
Subject: Re: PostgreSQL on XFS experiences?
Next
From: "Andrew Melton"
Date:
Subject: Hostname change - pgsql won't start