From: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bo Lorentsen <bl(at)netgroup(dot)dk>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Index optimization ? |
Date: | 2005-01-15 21:11:22 |
Message-ID: | 20050115211121.GP67721@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, Jan 15, 2005 at 01:27:49PM -0500, Tom Lane wrote:
> Bo Lorentsen <bl(at)netgroup(dot)dk> writes:
> > select * from sale where id = currval( 'sale_id_seq' );
>
> This is not legally optimizable into an indexscan, because currval() is
> a volatile function. (It's easy to construct cases where its value
> actually does change from row to row --- just use a nextval() as well.)
>
> You can fake it out in a couple of ways --- the recommended method is to
> wrap currval in a user-defined function that is misleadingly marked
> stable. I think it still works to just put the call in a sub-select:
> select * from sale where id = (select currval( 'sale_id_seq' ));
> but I take no responsibility if future improvements in the planner break
> that trick.
Would it make sense to have a version of currval that will only return
one value in a statement/transaction? So the first time it's called it
remembers what currval for that sequence is and always returns the same
value?
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-01-15 21:18:42 | Re: OID Usage |
Previous Message | Tom Lane | 2005-01-15 21:00:19 | Re: OID Usage |