On Thu, Jun 25, 2020 at 11:02:30AM -0700, Jeff Davis wrote: > If we have the GUCs there, then at least if someone comes to the > mailing list with a problem, we can offer them a temporary solution, > and have time to try to avoid the problem in a future release (tweaking > estimates, cost model, defaults, etc.). > > One idea is to have undocumented GUCs. That way we don't have to > support them forever, and we are more likely to hear problem reports.
Uh, our track record of adding GUCs just in case is not good, and removing them is even harder. Undocumented sounds interesting but then how do we even document when we remove it? I don't think we want to go there. Oracle has done that, and I don't think the user experience is good. Maybe we should just continue though beta, add an incompatibility item to the PG 13 release notes, and see what feedback we get. We know increasing work_mem gets us the exceed work_mem behavior, but that affects other nodes too, and I can't think of a way to avoid if spill is predicted except to disable hash agg for that query. I am still trying to get my head around why the spill is going to be so much work to adjust for hash agg than our other spillable nodes. What are people doing for those cases already? Do we have an real-world queries that are a problem in PG 13 for this? -- Bruce Momjian <[email protected]> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
