From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com> |
Subject: | Re: WIP: Covering + unique indexes. |
Date: | 2018-03-27 22:46:33 |
Message-ID: | CAH2-Wz=c_9PxXhSqTZNTH2+5LuzELryw-72eU9QSYSLd199+EA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 27, 2018 at 10:14 AM, Teodor Sigaev <teodor(at)sigaev(dot)ru> wrote:
>> b) I don't like an idea to limiting usage of that field if we can do not
>> that. Future usage could use it, for example, for different compression
>> technics or something else.Or even removing t_tid from inner tuples to save
>> 2 bytes in IndexTupleData. Of
>
> course, I remember about aligment, but it could be subject to change too in
> future.
This is contradictory. You seem to be arguing that we need to preserve
on-disk compatibility for an optimization that throws out on-disk
compatibility.
Saving a single byte per internal IndexTuple is not worth it. We could
actually save 2 bytes in *all* nbtree pages, by halving the size of
ItemId for nbtree -- we don't need lp_len, which is redundant, and we
could reclaim one of the status bits too, to get back a full 16 bits.
Also, we could use suffix truncation to save at least one byte in
almost all cases, even with the thinnest possible
single-integer-attribute IndexTuples. What you describe just isn't
going to happen.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-03-27 22:54:59 | Re: Using base backup exclusion filters to reduce data transferred with pg_rewind |
Previous Message | Dmitry Ivanov | 2018-03-27 22:46:31 | Re: new function for tsquery creartion |