Re: Rethinking TupleTableSlot deforming

Greg Stark <stark(at)mit(dot)edu> writes:
> On Fri, Jul 22, 2016 at 2:56 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> But I think the bigger issue than the above is actually that we're just
>> performing a lot of useless work in a number of common scenarios. We're
>> always deforming all columns up to the one needed. Very often that's a
>> lot of useless work.

> As I said when we chatted I'm a bit puzzled.

I'm really suspicious of this line of argument as well. It's possible
that if you only consider all-fixed-width, never-null columns, it might
look like deforming the columns before the one you need is a waste of
effort. But as soon as you relax either of those assumptions, you have
to crawl over the earlier columns anyway, and saving aside the results
is going to be close to free.

I can certainly believe that there's some merit in trying to arrange for
the columns we need to be earlier rather than later. In a sorting or
grouping step, we know we only need access to certain columns --- but
those columns are likely to be at the end not the beginning. If we're
doing a projection step anyway to construct the input, we could probably
rearrange that. Maybe we could even go further, and require the planner
to always set up the input so that the sort/group columns are exactly 1..N
in order, removing the need for the executor to cope with any variation.

regards, tom lane