Re: offset and limit in update and subselect - Mailing list pgsql-hackers

From Lincoln Yeoh
Subject Re: offset and limit in update and subselect
Date
Msg-id 3.0.5.32.20010225194248.00b47320@192.228.128.13
Whole thread Raw
In response to Re: offset and limit in update and subselect  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: offset and limit in update and subselect  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
At 05:07 PM 2/24/01 -0500, Tom Lane wrote:
>is not a defined concept according to SQL.  Even if we allowed queries
>such as you've described, the results would not be well-defined, but
>would change at the slightest provocation.  The implementation feels
>itself entitled to rearrange tuple order whenever the whim strikes it.
>
>As the documentation tries hard to make plain, LIMIT/OFFSET are only
>guaranteed to produce reproducible results if there's also an ORDER BY
>that constrains the tuples into a unique ordering.

Hi,

Would it then be fine to use update ... limit in the following scenario?

I have a todo queue:

create table todo ( task text, pid int default 0);

The tasks are inserted into the todo table.

Then the various worker processes do the following update to grab tasks
without duplication.

update todo set pid=$mypid where pid=0 limit 1;

For me it doesn't matter what which row each worker gets, as long as they
only get one each and they are not the same.

What would the performance impact of "order by" be in a LIMIT X case? Would
it require a full table scan?

Thanks,
Link.



pgsql-hackers by date:

Previous
From: Ola Sundell
Date:
Subject: jdbc driver hack
Next
From: Peter Eisentraut
Date:
Subject: Re: PL/SQL-to-PL/pgSQL-HOWTO + PL/pgSQL documentation