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 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])