Re: Rethinking TupleTableSlot deforming

On 2016-07-22 15:00:32 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2016-07-22 10:09:18 -0400, Tom Lane wrote:
> >> 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.
>
> But that's nonsense. We don't copy varlena datums during tuple deforming,
> only save aside pointers to them.

Indeed.

I've hacked up a test for this, I'll dig that up, and show the results.

> Well, it's a question of whether an extra projection at the scan level is
> worth the savings in column access during the sort or group stage. My gut
> feeling is that it very likely would be a win for a multicolumn sort.
> (For a single sort key column we already amortize fetching of the column
> datum, so maybe not so much in that case.)
>
> Whether the column is needed at upper levels doesn't seem relevant to me.
> setrefs.c will find it wherever it is.

Well, the projection is what I was thinking of.

Andres