Re: Brain dump: btree collapsing
От | Hannu Krosing |
---|---|
Тема | Re: Brain dump: btree collapsing |
Дата | |
Msg-id | 1045206446.1386.6.camel@fuji.krosing.net обсуждение исходный текст |
Ответ на | Re: Brain dump: btree collapsing (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Brain dump: btree collapsing
|
Список | pgsql-hackers |
Tom Lane kirjutas R, 14.02.2003 kell 01:13: > Hannu Krosing <hannu@tm.ee> 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
В списке pgsql-hackers по дате отправления: