I wrote:
Robert Haas robertmh...@gmail.com writes:
Could the desired behavior be obtained using a CTE?
Nope, we push FOR UPDATE into WITHs too. I don't really see any way to
deal with this without some sort of semantic changes.
... although on reflection, I'm not sure *why* we push FOR
On Tue, Oct 27, 2009 at 11:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Robert Haas robertmh...@gmail.com writes:
Could the desired behavior be obtained using a CTE?
Nope, we push FOR UPDATE into WITHs too. I don't really see any way to
deal with this without some sort of semantic
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 27, 2009 at 11:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What I am thinking we should do is define that FOR UPDATE happens before
ORDER BY or LIMIT normally, but that if the FOR UPDATE is inherited from
an outer query level, it happens
On Tue, Oct 27, 2009 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 27, 2009 at 11:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What I am thinking we should do is define that FOR UPDATE happens before
ORDER BY or LIMIT normally, but that if
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 27, 2009 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right, the case would be something like
select * from
(select * from foo order by x limit n) ss
for update of ss;
That's a pretty odd construction.
Dunno
I wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 27, 2009 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right, the case would be something like
select * from
(select * from foo order by x limit n) ss
for update of ss;
That's a pretty odd
Tom Lane escribió:
Robert Haas robertmh...@gmail.com writes:
This seems like it could potentially introduce a performance
regression, but the current behavior is so bizarre that it seems like
we should still change it.
Yeah, it could definitely run slower than the existing code ---
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Yeah, it could definitely run slower than the existing code --- in
particular the combination of all three (FOR UPDATE ORDER BY LIMIT)
would tend to become a seqscan-and-sort rather than possibly just
reading one end of an
On Mon, Oct 26, 2009 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Yeah, it could definitely run slower than the existing code --- in
particular the combination of all three (FOR UPDATE ORDER BY LIMIT)
would tend to become
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 26, 2009 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
One problem with this is that there isn't any good way for someone to
get back the old behavior if they want to. Which might be a perfectly
reasonable thing, eg if they know that no
I wrote:
Robert Haas robertmh...@gmail.com writes:
Could the desired behavior be obtained using a CTE?
Nope, we push FOR UPDATE into WITHs too. I don't really see any way to
deal with this without some sort of semantic changes.
... although on reflection, I'm not sure *why* we push FOR
Greg Stark gsst...@mit.edu writes:
On Sun, Oct 25, 2009 at 7:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
All that we have to do to fix the first one is to put the LockRows node
below the Limit node instead of above it. The solution for the second
one is to also put LockRows underneath the Sort
On Oct 25, 2009, at 10:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Now that we've got a hopefully-non-broken implementation of SELECT FOR
UPDATE locking as a plan node, we can finally contemplate fixing two
misbehaviors that are called out on the SELECT reference page:
It is possible for a
Robert Haas robertmh...@gmail.com writes:
On Oct 25, 2009, at 10:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... The solution for the second
one is to also put LockRows underneath the Sort node, and to regard its
output as unsorted so that a Sort node will certainly be generated.
(This in turn
14 matches
Mail list logo
