Re: Rethinking TupleTableSlot deforming

On 2016-07-22 10:09:18 -0400, Tom Lane wrote:
> 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.

Not according to my measurements. And that doesn't seems that
surprising. For a null check you'll need to access (not cheaply so!) the
null bitmap, to skip a varlena datum one needs to access the varlena
header. Copying the actual datum, *especially* in the varlena case, is a
more expensive than that; especially because otherwise you'll often not
have to touch the source cachelines at all.

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

Oh, that's a neat idea as well.

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

I guess that columns both returned to the upper node, and involved in
sorting would make it hard to entirely and efficiently rely on that,
without forcing more expensive projections. But it's probably worth
tinkering with.

Greetings,

Andres Freund