Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates
Date
Msg-id CAM3SWZS6nPJW8dT43VM+kBu0E-uFeR0H+vaj_zzxszj08CRenA@mail.gmail.com
Whole thread Raw
In response to Re: Reusing abbreviated keys during second pass of ordered [set] aggregates  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates
Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates
List pgsql-hackers
On Fri, Sep 25, 2015 at 2:39 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> This needs a rebase, there are several conflicts in src/backend/executor/nodeAgg.c

I attached a revised version of the second patch in the series, fixing
this bitrot.

I also noticed a bug in tuplesort's TSS_SORTEDONTAPE case with the
previous patch, where no final on-the-fly merge step is required (no
merge step is required whatsoever, because replacement selection
managed to produce only one run). The function mergeruns() previously
only "abandoned" abbreviated ahead of any merge step iff there was
one. When there was only one run (not requiring a merge) it happened
to continue to keep its state consistent with abbreviated keys still
being in use. It didn't matter before, because abbreviated keys were
only for tuplesort to compare, but that's different now.

That bug is fixed in this revision by reordering things within
mergeruns(). The previous order of the two things that were switched
is not at all significant (I should know, I wrote that code).

Thanks
--
Peter Geoghegan

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Memory prefetching while sequentially fetching from SortTuple array, tuplestore
Next
From: Michael Paquier
Date:
Subject: Re: Postgres service stops when I kill client backend on Windows