Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates
Date: 2015-10-11 01:03:12
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Fri, Sep 25, 2015 at 2:39 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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).

Peter Geoghegan

Attachment Content-Type Size
0002-Reuse-abbreviated-keys-in-ordered-set-aggregates.patch text/x-patch 18.2 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-10-11 03:55:21 Re: Postgres service stops when I kill client backend on Windows
Previous Message Peter Geoghegan 2015-10-11 00:20:05 Re: Memory prefetching while sequentially fetching from SortTuple array, tuplestore