From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | 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-03 04:02:08 |
Message-ID: | CAH2-Wzk-PrK7wtV98HtWA2POXjzm8hnaCR32FXSCCf8XP8Ur9A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 2, 2018 at 4:27 PM, Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> I thought abut that another time and I decided that it would be safer
> to use 13th bit in index tuple flags. There are already attempt to
> use whole 6 bytes of tid for not heap pointer information [1]. Thus, it
> would be safe to use 13th bit for indicating alternative offset meaning
> in pivot tuples, because it wouldn't block further work. Revised patchset
> in the attachment implements it.
This is definitely not the only time someone has talked about this
13th bit -- it's quite coveted. It also came up with UPSERT, and with
WARM. That's just the cases that I can personally remember.
I'm glad that you found a way to make this work, that will keep things
flexible for future patches, and make testing easier. I think that we
can find a flexible representation that makes almost everyone happy.
> I don't know. We still need an offset number to check expected number
> of attributes. Passing index tuple as separate attribute would be
> redundant and open door for extra possible errors.
You're right. I must have been tired when I wrote that. :-)
>> Do you store an attribute number in the "minus infinity" item (the
>> leftmost one of internal pages)? I guess that that should be zero,
>> because it's totally truncated.
>
>
> Yes, I store zero number of attributes in "minus infinity" item. See this
> part of the patch.
> However, note that I've to store (number_of_attributes + 1) in the offset
> in order to correctly store zero number of attributes. Otherwise, assertion
> is faised in ItemPointerIsValid() macro.
Makes sense.
> Yes. But that depends on how difficulty to adopt patch to big picture
> correlate with difficulty, which non-adopted patch makes to that big
> picture. My point was that second difficulty isn't high. But we can be
> satisfied with implementation in the attached patchset (probably some
> small enhancements are still required), then the first difficulty isn't high
> too.
I think it's possible.
I didn't have time to look at this properly today, but I will try to
do so tomorrow.
Thanks
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-04-03 04:32:17 | Re: [HACKERS] Add support for tuple routing to foreign partitions |
Previous Message | Peter Geoghegan | 2018-04-03 03:45:30 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |