Re: Rethinking TupleTableSlot deforming

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rethinking TupleTableSlot deforming
Date: 2016-07-22 14:09:18
Message-ID: 20576.1469196558@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-07-22 14:52:35 Re: Curing plpgsql's memory leaks for statement-lifespan values
Previous Message Greg Stark 2016-07-22 13:33:32 Re: Rethinking TupleTableSlot deforming