| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bo Lorentsen <bl(at)netgroup(dot)dk> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Index optimization ? |
| Date: | 2005-01-15 18:27:49 |
| Message-ID: | 10434.1105813669@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Fuhr | 2005-01-15 18:32:41 | Re: Index optimization ? |
| Previous Message | Tom Lane | 2005-01-15 18:15:36 | Re: Pgsql taking a *lot* of CPU time (unkillable). |