Re: reset all update
От | Tom Lane |
---|---|
Тема | Re: reset all update |
Дата | |
Msg-id | 26646.992447135@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: reset all update (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-patches |
Bruce Momjian <pgman@candle.pha.pa.us> writes: >> BTW, I would recommend that you not add logic to suppress the assignment >> when the value is not changing. Now that there are assign_hooks for all >> variable types, it seems to me that it is the assign_hook's >> responsibility to decide whether it wants to optimize that case or not. > This assume the assign hooks have no negative effects. Should we call > them if the value isn't changed? It's the hook's responsibility not to do anything that's incorrect. Consider the other case: maybe the hook *needs* to do something even though the value is not really changing. I haven't got a good example offhand, but in cache-flush tasks that's not impossible. Or perhaps more plausible, there may be state not directly visible to GUC that needs to be checked, even when the displayable var itself is correct already. Bottom line: I'd rather require the hooks to be slightly intelligent than cripple them with a GUC-knows-better-than-they-do policy. The point of the hooks is to know things that the core GUC code doesn't, after all. regards, tom lane
В списке pgsql-patches по дате отправления: