Horton

Re: tuplesort memory usage: grow_memtuples

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndQuadrant.com>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-10-16T13:24:12Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Incorporate a couple of recent tuplesort.c improvements into tuplestore.c.

On 16 October 2012 13:42, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 14 October 2012 09:19, Simon Riggs <simon@2ndquadrant.com> wrote:
>> This is a very useful optimisation, for both the low and the high end.
>
> Well, I'm about ready to mark this one "ready for committer". There is
> this outstanding issue in my revision of August 17th, though:
>
> +               /*
> +                * XXX: This feels quite brittle; is there a better principled approach,
> +                * that does not violate modularity?
> +                */
> +               newmemtupsize = (int) floor(oldmemtupsize * allowedMem / memNowUsed);
> +               state->fin_growth = true;
>
> I suppose that I should just recognise that this *is* nothing more
> than a heuristic, and leave it at that.

It's a simple and reasonable heuristic, and a great improvement on the
previous situation.

If you describe in detail that it is a heuristic and why that is
proposed over other approaches that should be sufficient for future
generations to read and understand.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services