Обсуждение: pgsql: Again fix initialization of auto-tuned effective_cache_size.
Again fix initialization of auto-tuned effective_cache_size. The previous method was overly complex and underly correct; in particular, by assigning the default value with PGC_S_OVERRIDE, it prevented later attempts to change the setting in postgresql.conf, as noted by Jeff Janes. We should just assign the default value with source PGC_S_DYNAMIC_DEFAULT, which will have the desired priority relative to the boot_val as well as user-set values. There is still a gap in this method: if there's an explicit assignment of effective_cache_size = -1 in the postgresql.conf file, and that assignment appears before shared_buffers is assigned, the code will substitute 4 times the bootstrap default for shared_buffers, and that value will then persist (since it will have source PGC_S_FILE). I don't see any very nice way to avoid that though, and it's not a case to be expected in practice. The existing comments in guc-file.l look forward to a redesign of the DYNAMIC_DEFAULT mechanism; if that ever happens, we should consider this case as one of the things we'd like to improve. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/af930e606a3217db3909029c6c3f8d003ba70920 Modified Files -------------- src/backend/optimizer/path/costsize.c | 33 ++++++++++++--------------------- src/backend/utils/misc/guc-file.l | 1 + 2 files changed, 13 insertions(+), 21 deletions(-)
Hi, On 2014-03-20 16:58:42 +0000, Tom Lane wrote: > Again fix initialization of auto-tuned effective_cache_size. > > The previous method was overly complex and underly correct; in particular, > by assigning the default value with PGC_S_OVERRIDE, it prevented later > attempts to change the setting in postgresql.conf, as noted by Jeff Janes. > We should just assign the default value with source PGC_S_DYNAMIC_DEFAULT, > which will have the desired priority relative to the boot_val as well as > user-set values. > > There is still a gap in this method: if there's an explicit assignment of > effective_cache_size = -1 in the postgresql.conf file, and that assignment > appears before shared_buffers is assigned, the code will substitute 4 times > the bootstrap default for shared_buffers, and that value will then persist > (since it will have source PGC_S_FILE). I don't see any very nice way > to avoid that though, and it's not a case to be expected in practice. > The existing comments in guc-file.l look forward to a redesign of the > DYNAMIC_DEFAULT mechanism; if that ever happens, we should consider this > case as one of the things we'd like to improve. This still is pretty ugly. Couldn't we just have a function in costsize.c that returns the actual value and computes it based on NBuffers if set to -1? Which is also called by a show_hook? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund <andres@2ndquadrant.com> writes: > On 2014-03-20 16:58:42 +0000, Tom Lane wrote: >> Again fix initialization of auto-tuned effective_cache_size. > This still is pretty ugly. Couldn't we just have a function in > costsize.c that returns the actual value and computes it based on > NBuffers if set to -1? Which is also called by a show_hook? I agree that it's ugly, but what you're suggesting would have failure modes of its own. For example, reading out the value and then re-assigning what that says would change the actual stored value from -1 to something else, resulting in the value ceasing to track the underlying GUC. In the particular example at hand, that might not matter, since shared_buffers can't change anymore after the initial read of postgresql.conf. But it's certainly no good as a prototype solution for other GUCs, which I think is the main criterion for ugliness here. Basically, we do not have a good design for GUCs whose default is supposed to change based on other GUCs. I'd like to see that addressed in a more general fashion, but I don't know what the solution will be. Perhaps the real short-term question is whether we should revert this whole change in effective_cache_size's behavior until we do have that better design. regards, tom lane