On 2016-07-22 15:00:32 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers