Re: Sort performance cliff with small work_mem

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sort performance cliff with small work_mem
Date: 2018-05-02 16:42:56
Message-ID: CAH2-Wzkko2TmSfOrcxWjeT9pXS1yrdopaeeWaD43in4Xpv9cuw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 2, 2018 at 8:38 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> With a small work_mem values, maxTapes is always 6, so tapeSpace is 48 kB.
> With a small enough work_mem, 84 kB or below in this test case, there is not
> enough memory left at this point, so we don't subtract tapeSpace. However,
> with a suitably evil test case, you can get arbitrary close to the edge, so
> that we will subtract away almost all the remaining memory above, leaving
> only a few bytes for the tuples. In this example case, with work_mem='85
> kB', each quicksorted run consists of only 15 tuples on average.

This is an extreme example of the memtuples array and memory for
tuples becoming unbalanced. You'll have 1024 memtuples (24KiB), which
is rather a lot more than the 15 tuples that you can fit in this
example case.

I don't feel strongly about it, but arguably the minimum additional
amount of memory should be big enough that you have some chance of
using all 1024 SortTuples (the whole memtuples array).

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2018-05-02 17:05:43 GSOC 2018
Previous Message Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?= 2018-05-02 16:41:38 Re: Transform for pl/perl