Re: WIP: Covering + unique indexes.

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: WIP: Covering + unique indexes.
Дата
Msg-id CAH2-Wz=kCWuXeMrBCopC-tFs3FbiVxQNjjgNKdG2sHxZ5k2y3w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: Covering + unique indexes.  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Ответы Re: WIP: Covering + unique indexes.  (Teodor Sigaev <teodor@sigaev.ru>)
Список pgsql-hackers
On Tue, Apr 17, 2018 at 3:12 AM, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> Hmm, what do you think about making BTreeTupGetNAtts() take tupledesc
> argument, not relation>  It anyway doesn't need number of key attributes,
> only total number of attributes.  Then _bt_isequal() would be able to use
> BTreeTupGetNAtts().

That would make the BTreeTupGetNAtts() assertions quite a bit more
verbose, since there is usually no existing tuple descriptor variable,
but there is almost always a "rel" variable. The coverage within
_bt_isequal() does not seem important, because we only use it with the
page high key in rare cases, where _bt_moveright() will already have
tested the highkey.

> I think it's completely OK to fix broken things when you've to touch
> them.  Probably, Teodor would decide to make that by separate commit.
> So, it's up to him.

You're right to say that this old negative infinity tuple code within
_bt_insertonpg() is broken code, and not just dead code. The code
doesn't just confuse things (e.g. see recent commit 2a67d644). It also
seems like it could actually be harmful. This is code that could only
ever corrupt your database.

I'm fine if Teodor wants to commit that change separately, of course.

-- 
Peter Geoghegan


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] proposal: schema variables
Следующее
От: Kohei KaiGai
Дата:
Сообщение: [ANN] PG-Strom v2.0 is released