Re: pgsql: Again fix initialization of auto-tuned effective_cache_size.
От | Tom Lane |
---|---|
Тема | Re: pgsql: Again fix initialization of auto-tuned effective_cache_size. |
Дата | |
Msg-id | 956.1399397522@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Again fix initialization of auto-tuned effective_cache_size. (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: