On Fri, Mar 31, 2017 at 2:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Geoghegan <p...@bowt.ie> writes: >> On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers