Tom Lane wrote:
But note that barring backend crash, once all the scans are done it is
guaranteed that the hint will be removed --- somebody will be last to
update the hint, and therefore will remove it when they do heap_endscan,
even if others are not quite done. This is good in the sense that
Hi,
Anyways, this patch and the functionality introduced herein will be useful
in the CREATE .. INCLUDING INDEXES case too.
No doubt. But those are different features and we shouldn't confuse
'em; in particular not put behavior into the INCLUDING CONSTRAINTS case
that shouldn't be there.
On Mon, 2007-06-04 at 21:39 -0400, Tom Lane wrote:
idea of deleting the hint. But if we could change the hint behavior to
say start reading here, successive short LIMITed reads would all start
reading from the same point, which fixes both my reproducibility concern
and Heikki's original point
Jeff Davis [EMAIL PROTECTED] writes:
That's how it works now. Small limit queries don't change the location
in the hint, so if you repeat them, the queries keep starting from the
same place, and fetching the same tuples.
OK, maybe the problem's not as severe as I thought then.
On Mon, 2007-06-04 at 10:53 +0100, Heikki Linnakangas wrote:
I'm now done with this patch and testing it.
One difference between our patches is that, in my patch, the ending
condition of the scan is after the hint is set back to the starting
position.
That means, in my patch, if you do:
