Re: key = currval('tab_key_seq') choses SEQSCAN?!

From: Eric B(dot)Ridge <ebr(at)tcdi(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org, Brandon Craig Rhodes <brandon(at)oit(dot)gatech(dot)edu>
Subject: Re: key = currval('tab_key_seq') choses SEQSCAN?!
Date: 2004-02-26 02:29:33
Message-ID: 9D0E600A-6803-11D8-9391-000A95D98B3E@tcdi.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Feb 25, 2004, at 9:07 PM, Joe Conway wrote:

> Eric B.Ridge wrote:
>> I suppose this is obvious, but it's volatile because *other* backends
>> can change it while the current transaction is still in progress?
>
> No. Other backends don't affect currval, but your own might on a
> row-by-row basis. Consider:

gotcha. Stated differently, it's not volatile because, by design, it
doesn't always produce the same output for the same input.

> regression=# select nextval('seq'), currval('seq'), s from
> generate_series(1,4) as t(s);

OT: generate_series looks useful. Is this only in 7.5?

eric

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Shelby Cain 2004-02-26 04:18:59 Re: select statement against pg_stats returns inconsistent data
Previous Message Joe Conway 2004-02-26 02:07:32 Re: key = currval('tab_key_seq') choses SEQSCAN?!