From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: WIP: Covering + unique indexes. |
Date: | 2018-04-17 16:45:27 |
Message-ID: | CAH2-Wz=kCWuXeMrBCopC-tFs3FbiVxQNjjgNKdG2sHxZ5k2y3w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 17, 2018 at 3:12 AM, Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2018-04-17 16:56:59 | [ANN] PG-Strom v2.0 is released |
Previous Message | Pavel Stehule | 2018-04-17 16:28:19 | Re: [HACKERS] proposal: schema variables |