Re: offset and limit in update and subselect

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: (Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Timothy H(dot) Keitt" <Timothy(dot)Keitt(at)SUNYSB(dot)Edu>)
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: offset and limit in update and subselect
Date: 2001-02-25 11:42:48
Message-ID: 3.0.5.32.20010225194248.00b47320@192.228.128.13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2001-02-25 11:54:45 Re: PL/SQL-to-PL/pgSQL-HOWTO + PL/pgSQL documentation
Previous Message Ola Sundell 2001-02-25 11:15:07 jdbc driver hack