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).


Andres Freund

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to