Re: ORDER BY random() LIMIT 1 slowness

From: Jean-Luc Lachance <jllachan(at)nsd(dot)ca>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, "SZUCS =?iso-8859-1?Q?G=E1bor?=" <surrano(at)mailbox(dot)hu>, pgsql-general(at)postgresql(dot)org
Subject: Re: ORDER BY random() LIMIT 1 slowness
Date: 2002-12-18 20:22:06
Message-ID: 3E00D8EE.89743B3A@nsd.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Scott,

I understand it all.

If a programmer understand that currval() return the last_(used)_value
and did not himself call nextval() he should be aware of the caveat.

I did not want to make a big fuss of it. I will just use select
last_value myself since I am already aware of the caveat. :)

JLL

"scott.marlowe" wrote:
>
> On Wed, 18 Dec 2002, Jean-Luc Lachance wrote:
>
> > Alvara,
> >
> > But instead of returning an error, currval() should return last_value if
> > nextval() was not called (with all the caveat of couse). I think it
> > would be more usefull that way.
>
> no, that would be like walking around with a gun pointed at your foot, to
> quote Tom Lane.
>
> See my post on transactions and such. Remember that everything in
> Postgresql is designed to make transactions safe. currval working without
> a nextval or setval before it is dangerous in the exterme to transactions.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jessica Blank 2002-12-18 20:30:22 Re: Measuring CPU time use? (Another stupid question)
Previous Message scott.marlowe 2002-12-18 20:13:43 Re: To many connections Error