Re: Default setting for enable_hashagg_disk
От | Jeff Davis |
---|---|
Тема | Re: Default setting for enable_hashagg_disk |
Дата | |
Msg-id | ee1a7be071349b93c01ffb9ef4cf3a6830d9e780.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: Default setting for enable_hashagg_disk (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Default setting for enable_hashagg_disk
|
Список | pgsql-hackers |
On Mon, 2020-06-22 at 10:52 -0400, Robert Haas wrote: > So I feel like the really important thing here is to fix the cases > that don't come out well with default settings. ...with the caveat that perfection is not something to expect from our planner. > If we can't do that, > then the feature is half-baked and maybe should not have been > committed in the first place. HashAgg started out half-baked at the dawn of time, and stayed that way through version 12. Disk-based HashAgg was designed to fix it. Other major planner features generally offer a way to turn them off (e.g. parallelism, JIT), and we don't call those half-baked. I agree that the single GUC added in v13 (hashagg_avoid_disk_plan) is weird because it's half of a disable switch. But it's not weird because of my changes in v13; it's weird because the planner behavior in v12 was weird. I hope not many people need to set it, and I hope we can remove it soon. If you think we will never be able to remove the GUC, then we should think a little harder about whether we really need it. I am open to that discussion, but I don't think the presence of this GUC implies that disk-based hashagg is half-baked. Regards, Jeff Davis
В списке pgsql-hackers по дате отправления: