Re: Tuplesort merge pre-reading - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: Tuplesort merge pre-reading
Date
Msg-id CAGTBQpa8pzb3KgWZwqaBuXytQ79DqKPbP16NuS+ncoOx++OBRQ@mail.gmail.com
Whole thread Raw
In response to Re: Tuplesort merge pre-reading  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: Tuplesort merge pre-reading  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-hackers
On Fri, Sep 9, 2016 at 9:51 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
> On Fri, Sep 9, 2016 at 8:13 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>
>> Claudio, if you could also repeat the tests you ran on Peter's patch set on
>> the other thread, with these patches, that'd be nice. These patches are
>> effectively a replacement for
>> 0002-Use-tuplesort-batch-memory-for-randomAccess-sorts.patch. And review
>> would be much appreciated too, of course.
>>
>> Attached are new versions. Compared to last set, they contain a few comment
>> fixes, and a change to the 2nd patch to not allocate tape buffers for tapes
>> that were completely unused.
>
>
> Will do so

Well, here they are, the results.

ODS format only (unless you've got issues opening the ODS).

The results seem all over the map. Some regressions seem significant
(both in the amount of performance lost and their significance, since
all 4 runs show a similar regression). The worst being "CREATE INDEX
ix_lotsofitext_zz2ijw ON lotsofitext (z, z2, i, j, w);" with 4GB
work_mem, which should be an in-memory sort, which makes it odd.

I will re-run it overnight just in case to confirm the outcome.

Attachment

pgsql-hackers by date:

Previous
From: Jesper Pedersen
Date:
Subject: Re: Write Ahead Logging for Hash Indexes
Next
From: Peter Eisentraut
Date:
Subject: Re: increasing the default WAL segment size