Hannu Krosing <[EMAIL PROTECTED]> writes: > Tom Lane kirjutas R, 14.02.2003 kell 01:13: >> How is returning the same data twice not an "ill effect"?
> From earlier discussions I understood that there had been some work done > on using btrees for indexing arrays by storing each separate element in > a löeaf node. Surely that work must deal with not returning the same > tuple twice. The only mechanism that exists for that is to discard tuples that meet the qualification tests of previous indexscans. This cannot prevent returning the same tuple twice in one scan, if the index is so ill-behaved as to return the same pointer twice. I don't know what Vadim had in mind to support multiple index entries per tuple, but it's certainly not in the code yet. >> How will you wait for scans that you know nothing of to go past? >> Especially when they are going to be blocked by your own write lock >> on the left page? > could we just not lock (for more than just to ensure atomic writes) the > page but instead increment a "page version" on each write to detect > changes? How does that help? The left-moving indexscan still has no way to recover. It can't go back to the page it was on before and try to determine which entries you added there, because it has no reliable reference point to do so. The entry it previously returned might not be there anymore, and in a non-unique index key comparisons won't help. And even more to the point, how would it know you've changed the left page? It has no idea what the previous "page version" on the left page was, because it was never there before. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])