On 2017-03-31 13:44:52 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > The covering indexes patch [1] really needs a version of > > heap_form_tuple/index_form_tuple that allows to specify the number of > > columns in the to-be generated tuple. > > I was thinking about that this morning, and wondering why exactly it > would need such a thing. Certainly we're not going to store such a > truncated tuple in the index, so I assume that the purpose here is > just to pass around the tuple internally for some reason.
The patch does actually store truncated/key-only tuples in the hi keys / non-leaf-nodes, which don't need the "included" columns. > > Previously the faster expression > > evaluation stuff could also have benefited form the same for both > > forming and deforming tuples. > > Um, I didn't notice anyplace where that would have helped, certainly > not on the "form tuple" side. Tuples that don't meet their own tupdesc > don't seem to have wide application to me. It'd be useful for FieldStore - we'd not have to error out anymore if the number of columns changes (which I previously had "solved" by using MaxHeapAttributeNumber sized values/nulls array). Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
