Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Automatically setting work_mem

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Luke Lonergan <llonergan(at)greenplum(dot)com>, pgsql-patches(at)postgresql(dot)org, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Automatically setting work_mem
Date: 2006-04-22 17:38:53
Message-ID: 1145727534.3112.209.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
On Sat, 2006-04-22 at 13:17 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > I still do, for multi-user systems. Releasing unused memory from a large
> > CREATE INDEX will allow that memory to be swapped out, even if the brk
> > point can't be changed.
> Say what?  It can get "swapped out" anyway, whether we free() it or not.

Of course it can, but if the memory is not actively used by the sort
then it will be OK if that happens and fairly likely also. If we
actively use the memory for the sort it would is less likely to be
swapped out and a bad thing if it did.

> More to the point, though: I don't believe that the proposed patch is a
> good idea --- it does not reduce the peak sortmem use, which I think is
> the critical factor for a multiuser system, 

I agree peak memory use is the critical factor. There is only one
performsort in progress at any one time, though there can be many final
merges/retrievals in progress concurrently. If the majority of the
memory used by performsoft is released afterwards then it can be made
available for subsequent sorts/hashes etc without increasing further the
peak mem use.

> and what it does do is
> reduce the locality of access to the sort temp file during the merge
> phases.  That will definitely have some impact; maybe small, but some;
> and I don't see where the benefit comes in.

That I already accept.

  Simon Riggs

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-04-22 18:17:56
Subject: Re: TODO items..
Previous:From: Tom LaneDate: 2006-04-22 17:34:42
Subject: Re: TODO items..

pgsql-patches by date

Next:From: Tom LaneDate: 2006-04-22 17:57:23
Subject: Re: patch to have configure check if CC is intel C compiler
Previous:From: Jim C. NasbyDate: 2006-04-22 17:26:19
Subject: Re: [HACKERS] Automatically setting work_mem

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group