From: | Hannu Krosing <hannu(at)skype(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Automatically setting work_mem |
Date: | 2006-03-17 21:07:37 |
Message-ID: | 1142629657.4044.3.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Ühel kenal päeval, R, 2006-03-17 kell 09:46, kirjutas Tom Lane:
> "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-03-17 21:35:03 | Re: Seperate command-line histories for seperate databases |
Previous Message | Tom Lane | 2006-03-17 20:27:36 | Re: Seperate command-line histories for seperate databases |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-03-17 21:45:17 | Re: Automatically setting work_mem |
Previous Message | Tom Lane | 2006-03-17 20:18:14 | Re: Automatically setting work_mem |