Re: Automatically setting work_mem - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Automatically setting work_mem
Date
Msg-id 1142629657.4044.3.camel@localhost.localdomain
Whole thread Raw
In response to Re: Automatically setting work_mem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Automatically setting work_mem
List pgsql-hackers
Ühel kenal päeval, R, 2006-03-17 kell 09:46, kirjutas Tom Lane:
> "Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
> > So what's the difference between these two strategy?
> > (1) Running time: do they use the same amount of memory? Why option 2 is
> > better than 1?
> > (2) Idle time: after sort done, option 1 will return all 1024 to the OS and
> > 2 will still keep 512?
> 
> Point 2 is actually a serious flaw in Simon's proposal, because there
> is no portable way to make malloc return freed memory to the OS. 

So perhaps we could keep the shaded_work_mem in actual shared memory,
and alloc it to processes from there ?

We probably can't get it into a continuous chunk, but alt least we can
give it back for other backends to use when done.

> My own thoughts about the problems with our work_mem arrangement are
> that the real problem is the rule that we can allocate work_mem per sort
> or hash operation; this makes the actual total memory use per backend
> pretty unpredictable for nontrivial queries.  I don't know how to fix
> this though.  The planner needs to know the work_mem that will be used
> for any one of these operations in order to estimate costs, so simply
> trying to divide up work_mem among the operations of a completed plan
> tree is not going to improve matters.

Why not maybe make the work_mem allocation one of the variable
parameters thet is fed to planner, and try optimising for different sets
of sub-work_mems ?

---------------
Hannu




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Seperate command-line histories for seperate databases
Next
From: Bruce Momjian
Date:
Subject: Re: Seperate command-line histories for seperate databases