Re: [HACKERS] Rethinking TupleTableSlot deforming

Andres Freund wrote: > Hi, > > I've previously mentioned (e.g. [1]) that tuple deforming is a serious > bottlneck. I've also experimented successfully [2] making > slot_deform_tuple() faster. I'm currently messing with making heapam.c be just one possible implementation of tuple storage, to

Re: [HACKERS] Rethinking TupleTableSlot deforming

Andres Freund writes: > On 2016-07-22 15:00:32 -0400, Tom Lane wrote: >> 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. > Well, the projection is what I was thinking of. One

Re: [HACKERS] Rethinking TupleTableSlot deforming

On 2016-07-22 15:00:32 -0400, Tom Lane wrote: > Andres Freund 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 > >>

Re: [HACKERS] Rethinking TupleTableSlot deforming

On 7/22/16 1:58 PM, Andres Freund wrote: On 2016-07-22 13:51:31 -0500, Jim Nasby wrote: Another option would be to remember the tuple offsets (NOT attcacheoff) that have been computed as well as whether a varlena attribute has actually been deformed. That eliminates the need to pre-declare what

Re: [HACKERS] Rethinking TupleTableSlot deforming

Andres Freund 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

Re: [HACKERS] Rethinking TupleTableSlot deforming

On 2016-07-22 13:51:31 -0500, Jim Nasby wrote: > Another option would be to remember the > tuple offsets (NOT attcacheoff) that have > been computed as well as whether a > varlena attribute has actually been > deformed. That eliminates the need to > pre-declare what attributes you're > allowed to

Re: [HACKERS] Rethinking TupleTableSlot deforming

On 7/22/16 1:35 PM, Andres Freund wrote: Sure, it's intentional. But not working that well. The problem is that very often we actually don't ever access the preceding columns. Sometimes that knowledge would let us skip directly to the interesting column(s) (fixed width, no nulls columns

Re: [HACKERS] Rethinking TupleTableSlot deforming

On 2016-07-22 10:09:18 -0400, Tom Lane wrote: > Greg Stark writes: > > On Fri, Jul 22, 2016 at 2:56 AM, Andres Freund 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

Re: [HACKERS] Rethinking TupleTableSlot deforming

On 2016-07-22 14:33:32 +0100, Greg Stark wrote: > On Fri, Jul 22, 2016 at 2:56 AM, Andres Freund 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

Re: [HACKERS] Rethinking TupleTableSlot deforming

Greg Stark writes: > On Fri, Jul 22, 2016 at 2:56 AM, Andres Freund 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

Re: [HACKERS] Rethinking TupleTableSlot deforming

On Fri, Jul 22, 2016 at 2:56 AM, Andres Freund 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

[HACKERS] Rethinking TupleTableSlot deforming

Hi, I've previously mentioned (e.g. [1]) that tuple deforming is a serious bottlneck. I've also experimented successfully [2] making slot_deform_tuple() faster. But nontheless, tuple deforming is still a *major* bottleneck in many cases, if not the *the* major bottleneck. We could partially