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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [PROPOSAL] Covering + unique indexes.
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [PROPOSAL] Covering + unique indexes.