On Sat, 2005-03-19 at 12:57 -0500, Tom Lane wrote:
> That means we can go ahead with providing a GUC variable to make the
> array size user-selectable. I was thinking of calling it either
> "local_buffers" (in contrast to "shared_buffers") or "temp_buffers"
> (to emphasize the fact that they're used for temporary tables).
> Anyone have a preference, or a better alternative?
> Comments?
All of that is good news...
Currently, we already have a GUC that describes the amount of memory we
can use for a backend, work_mem. Would it not be possible to continue to
use that setting and resize the temp_buffers area as needed so that
work_mem was not exceeded - and so we need not set local_temp_buffers?
It will become relatively hard to judge how to set work_mem and
local_temp_buffers for larger queries, and almost impossible to do that
in a multi-user system. To do that, we would need some additional
feedback that could be interpreted so as to judge how large to set
these. Perhaps to mention local buffer and memory usage in an EXPLAIN
ANALYZE? It would be much better if we could decide how best to use
work_mem according to the query plan that is just about to be executed,
then set all areas accordingly. After all, not all queries would use
both limits simultaneously.
This is, of course, a nice problem to have. :-)
If we must have a GUC, local_temp_buffers works better for me.
local_buffers is my second choice because it matches the terminology
used everywhere in the code and also because temp_buffers sounds like it
is a global setting, which it would not be.
Best Regards, Simon Riggs
