On Fri, Mar 31, 2017 at 2:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Geoghegan <pg@bowt.ie> writes:
>> On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Hm. Since index tuples lack any means of indicating the actual number
>>> of columns included (ie there's no equivalent of the natts field that
>>> exists in HeapTupleHeaders), I think that this is an unreasonably
>>> dangerous design. It'd be better to store nulls for the missing
>>> fields. That would force a null bitmap to be included whether or
>>> not there were nulls in the key columns, but if we're only doing it
>>> once per page that doesn't seem like much cost.
>
>> We're doing it once per page for the leaf page high key, but that's
>> used as the downlink in the second phase of a B-Tree page split --
>> it's directly copied. So, including a NULL bitmap would make
>> Anastasia's patch significantly less useful,
>
> I think you are failing to get the point. I am not on about whether
> we need a few bytes more or less, I am on about whether the patch
> even works. As an example, it's quite unclear what the width of
> such an index tuple's nulls bitmap will be if it exists, and there
> certainly will be cases where it must exist because of nulls in the
> keys columns. I also think we're setting up a situation where tools
> like amcheck and pg_filedump are going to be unable to cope, because
> figuring out what a particular tuple contains is going to require context
> they haven't got. It just seems way too dangerous.
So, we end up with heap tuples with different numbers of attributes
all the time, whenever you add a column. It works fine - on decoding,
the additional columns will be treated as null (unless somebody
commits Serge Rielau's patch, which regrettably nobody has gotten
around to reviewing). Why is this case different?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
