I wrote:
> Robert Haas writes:
>> On Tue, Oct 27, 2009 at 1:06 PM, Tom Lane 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 why you th
Robert Haas writes:
> On Tue, Oct 27, 2009 at 1:06 PM, Tom Lane 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 why you think that. That's e
On Tue, Oct 27, 2009 at 1:06 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 27, 2009 at 11:22 AM, Tom Lane 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
Robert Haas writes:
> On Tue, Oct 27, 2009 at 11:22 AM, Tom Lane 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 after the sub-select's ORDER BY or
>>
On Tue, Oct 27, 2009 at 11:22 AM, Tom Lane wrote:
> I wrote:
>>> Robert Haas 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 o
I wrote:
>> Robert Haas 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 UPDATE into
> W
Greg Stark writes:
> On Sun, Oct 25, 2009 at 7:34 PM, Tom Lane 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 node, and to regard its
>>
I wrote:
> Robert Haas 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 UPDATE into
WITHs. T
Robert Haas writes:
> On Mon, Oct 26, 2009 at 10:30 AM, Tom Lane 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 concurrent update is supposed
>>
On Mon, Oct 26, 2009 at 10:30 AM, Tom Lane wrote:
> Alvaro Herrera 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 p
Alvaro Herrera 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 index. However, I
Tom Lane escribió:
> Robert Haas 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 --- in
> particul
Robert Haas writes:
> On Oct 25, 2009, at 10:34 PM, Tom Lane 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 implies that we should prefer
On Oct 25, 2009, at 10:34 PM, Tom Lane 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 SELECT command using
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 SELECT command using both LIMIT and FOR
UPDATE/SHARE clauses to re
15 matches
Mail list logo
