[Bizgres-general] Question: Is 64-bit cache support valuable?

[Simon Riggs]

On Thu, 2005-07-21 at 16:41 -0500, Jim C. Nasby wrote:
> On Thu, Jul 21, 2005 at 11:23:56AM +0100, Simon Riggs wrote:
>  
> > Most important thing is that the memory management needs to be a Top-
> > down Memory Allocation scheme. So, all work_mem requests get allocated
> > from a single top-level pool. This is defined as total_work_mem which is
> > a SUSET parameter allowing the administrator to change it while the
> > server is running. This is possible because work_mem is a *dynamic*
> > memory limit, not a pre-allocation, like shared_buffers. We may not use
> > all of total_work_mem at any point in time.
> 
> Something to consider is how this will interact with buffering/caching.
> Right now, with the consensus that it's best to let the OS handle
> caching, it's important that we don't hold on to memory that's not being
> actively used. In the future, if we end up with a caching scheme that's
> better than plane OS caching, it will become important to allow unused
> memory to be used for buffering.

No; sorry for any confusion. The idea of a top-level pool is conceptual
only. As I said, it is not a pre-allocation like shared_buffers.

This is about better management of work_mem and not about anything
else. 

Most people are unable to set work_mem very high because they risk
causing swapping. Especially since there isn't an easy way to tell how
much work_mem is in use across the PostgreSQL server and then use that
information to make a judicious choice at run-time.

Best Regards, Simon Riggs