Re: Rethinking TupleTableSlot deforming

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. I've experimented with selectively replacing
> slot_getattr calls heap_getattr(), and for some queries that can yield
> massive speedups. And obviously significant slowdowns in others. That's
> the case even when preceding columns are varlena and/or contain nulls.
> I.e. a good chunk of the problem is storing the results of deforming,
> not accessing the data.

As I said when we chatted I'm a bit puzzled. My understanding was that
the whole point of the "slots" thing was precisely to avoid this kind
of extra work. So I would love to learn where my understanding
diverges from reality. I wonder if there's some simple bug in the code
leading to it not doing what it's intended to do.

My understanding is that the idea of slots is that when we decode the
Nth attribute we decode every attribute up until that attribute and
have somewhere to put it -- in the slot. When we later refer to an
earlier attribute we can just fetch it from the slot directly. This is
the difference between using slot_getattr and heap_getattr directly.

--
greg