Re: SP-GiST bug.
От | Teodor Sigaev |
---|---|
Тема | Re: SP-GiST bug. |
Дата | |
Msg-id | 53889BD6.4020401@sigaev.ru обсуждение исходный текст |
Ответ на | Re: SP-GiST bug. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SP-GiST bug.
Re: SP-GiST bug. |
Список | pgsql-hackers |
> The point I'm making is that the scenario your test case exposes is not > an infinite loop of picksplits, but an infinite loop of choose calls. Thank you, now I see what I missed before. After some brainstorming, it's possible to use '\0' only as end of string marker. The idea is: when we split allthesame tuple to upper/lower we copy node label to upper tuple instead of set it to '\0'. Node labels of lower tuple will be unchanged but should be ignored for reconstructionValue - and they are ignored because of allTheSame flag. See attached patch. Unfortunately, it will break on-disk compatibility. Although it will not cause a panic/error/coredump allTheSame approach will not find tuples. Users should recreate spgist indexes over text column. > It's certainly possible that we could/should change what checkAllTheSame > is doing --- on re-reading the comment, I'm not really sure that the > scenario it's concerned about can happen. However, that will not fix I rewrited a patch to fix missed way - allTheSame result of picksplit and tooBig is set. I believe this patch is still needed because it could make a tree more efficient as it was demonstrated for quad tree. this patch doesn't break on-disk compatibility, although index recreation is recommended. -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
Вложения
В списке pgsql-hackers по дате отправления: