Re: Implementation of LIMIT on DELETE and UPDATE statements - Mailing list pgsql-patches

From Yury Bokhoncovich
Subject Re: Implementation of LIMIT on DELETE and UPDATE statements
Date
Msg-id Pine.LNX.4.33.0209252011120.1392-100000@panda.center-f1.ru
Whole thread Raw
In response to Re: Implementation of LIMIT on DELETE and UPDATE statements  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Implementation of LIMIT on DELETE and UPDATE statements  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
List pgsql-patches
Hello!

On Mon, 23 Sep 2002, Tom Lane wrote:

> The above is really a perfect example of why this feature isn't safe:
> it would lead people to make unwarranted assumptions.  The fact that
> such-and-such a tuple appeared second in the output of LIMIT 10 OFFSET
> 20 does *not* mean that it would be selected by LIMIT 1 OFFSET 21.  The

Agreed. But if records are inserted by INSERT (times) values (now()) and
those are selected ORDER BY times - the result is probably well
determined.;)

> planner is entitled to (and often does) choose different query plans
> depending on the limit/offset values.

Hm...I had always supposed that LIMIT/OFFSET is a trick to get the
functionality of cursors w/o their overhead.
And nobody wonders when there's sequential scan in cursor upto a required
bunch of records, then bulk delete/update of those.

I don't insist on the feature, just some thoughts.

BTW, doing limit/offset w/o ORDER BY is useless anyway IMHO.:)

--
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: byg@center-f1.ru.
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.



pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: cleanup standard includes
Next
From: Stephan Szabo
Date:
Subject: Re: Implementation of LIMIT on DELETE and UPDATE statements