Re: [PROPOSAL] Covering + unique indexes.
От | Peter Geoghegan |
---|---|
Тема | Re: [PROPOSAL] Covering + unique indexes. |
Дата | |
Msg-id | CAM3SWZTSu8OSTdRg4wEwmSd8okCMM-cbvuChqqn-niaUcY7GPg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] Covering + unique indexes. (Peter Geoghegan <pg@heroku.com>) |
Список | pgsql-hackers |
On Mon, Mar 14, 2016 at 8:43 PM, Peter Geoghegan <pg@heroku.com> wrote: > > Does this work with amcheck? Maybe it works with bt_index_check(), but > not bt_index_parent_check()? I think that you need to make sure that > _bt_compare() knows about this, too. That's because it isn't good > enough to let a truncated internal IndexTuple compare equal to a > scankey when non-truncated attributes are equal. I think you need to > have an imaginary "minus infinity" attribute past the first > non-truncated attribute (i.e. "minus infinity value" for the first > *truncated* attribute). That way, the downlinks will always be lower > bounds when the non-"included"/truncated attributes are involved. This > seems necessary. No? Maybe can store information about minus infinity attributes in "itup->t_tid.ip_posid". As you know, this is unused within internal/non-leaf pages, whose downlink items only need a block number (the child's block number/location on disk for that particular downlink). That's a bit ugly, but there are plenty of bits available from there, so use them if you need them. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: