Re: [HACKERS] Is FOR UPDATE an optimization fence?

2009-10-12 Thread Merlin Moncure
On Mon, Oct 12, 2009 at 1:59 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane wrote: >>> Of course the downside of changing it is that queries that worked fine >>> before might work differently (and much slower) now; first because not >>> flattening the sub

Re: [HACKERS] Is FOR UPDATE an optimization fence?

2009-10-12 Thread Tom Lane
Robert Haas writes: > On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane wrote: >> Of course the downside of changing it is that queries that worked fine >> before might work differently (and much slower) now; first because not >> flattening the sub-select might lead to a worse plan, and second because >

Re: [HACKERS] Is FOR UPDATE an optimization fence?

2009-10-11 Thread Tom Lane
Robert Haas writes: > On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane wrote: >> It's an entirely trivial code change either way.  I'm inclined to think >> that we should prevent flattening, on the grounds of least astonishment. > It seems like this is somewhat related to the question of embedding an

Re: [HACKERS] Is FOR UPDATE an optimization fence?

2009-10-11 Thread Robert Haas
On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane wrote: > I'm fooling around with pushing FOR UPDATE locking into a new plan node > type, and I just noticed a behavior that seems a bit bogus. > Historically we have dealt with FOR UPDATE in sub-selects by flattening > the sub-select if we could, because

Re: [HACKERS] Is FOR UPDATE an optimization fence?

2009-10-11 Thread Tom Lane
Markus Wanner writes: > BTW: how do other databases deal with this? Anything of relevance in the > SQL standards? SQL99 treats FOR UPDATE as an attribute of DECLARE CURSOR, so there's no way for it to appear in a sub-select per spec. (In general our approach to FOR UPDATE is only loosely related

Re: [HACKERS] Is FOR UPDATE an optimization fence?

2009-10-11 Thread Markus Wanner
Hi, Tom Lane wrote: > It's an entirely trivial code change either way. I'm inclined to think > that we should prevent flattening, on the grounds of least astonishment. Yeah, I also tend towards making FOR UPDATE an optimization fence (that's how I understood the non-flattening approach). While i

[HACKERS] Is FOR UPDATE an optimization fence?

2009-10-11 Thread Tom Lane
I'm fooling around with pushing FOR UPDATE locking into a new plan node type, and I just noticed a behavior that seems a bit bogus. Historically we have dealt with FOR UPDATE in sub-selects by flattening the sub-select if we could, because the alternative was to fail altogether. For example, consi