Re: Tuplesort merge pre-reading

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Tuplesort merge pre-reading
Date: 2016-09-22 00:40:23
Message-ID: CAGTBQpZxRxcDg95z++-W3mSE_=FwDgNOiVv6BS-XFpoVK4VxfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Tue, Sep 20, 2016 at 3:34 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Fri, Sep 9, 2016 at 9:51 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
>> On Fri, Sep 9, 2016 at 8:13 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)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.

A new run for "patched" gives better results, it seems it was some
kind of glitch in the run (maybe some cron decided to do something
while running those queries).

Attached

In essence, it doesn't look like it's harmfully affecting CPU
efficiency. Results seem neutral on the CPU front.

Attachment Content-Type Size
logtape_preload_timings.ods application/vnd.oasis.opendocument.spreadsheet 62.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2016-09-22 01:11:29 Re: Relax requirement for INTO with SELECT in pl/pgsql
Previous Message AP 2016-09-21 23:47:23 Re: Hash Indexes