Tom Lane kirjutas R, 14.02.2003 kell 01:13: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > But if we would allow the scans to find the same keys twice without ill > > effects (as was suggested earlier, for using btrees to index arrays), > > 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. > > then we could possibly 1) copy the key to the right 2) wait for all > > right-to-left scans that have fallen between old and new values to pass > > and only then 3) delete the "old left" key. > > 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? ------------ Hannu ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
