Re: Default setting for enable_hashagg_disk (hash_mem)
От | Peter Geoghegan |
---|---|
Тема | Re: Default setting for enable_hashagg_disk (hash_mem) |
Дата | |
Msg-id | CAH2-Wz=aRWvw87z-3kseECPXOSbNWh6_pih8pyitkGzgFCg3Ow@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Default setting for enable_hashagg_disk (hash_mem) (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Tue, Jul 7, 2020 at 10:12 AM Andres Freund <andres@anarazel.de> wrote: > I think it makes no too much sense to plan invent something like > hash_mem for v13, it's clearly too much work. That's a seperate > discussion from having something like it for v14. Can you explain why you believe that to be the case? It seems quite possible that there is some subtlety that I missed in grouping sets or something like that. I would like to know the specifics, if there are any specifics. > My conclusion about this topic is that I think we'll be doing our users > a disservice by not providing an escape hatch, but that I also don't > have the energy / time to fight for it further. This is a long thread > already, and I sense little movement towards a conclusion. An escape hatch seems necessary. I accept that a hard disabling of spilling at execution time meets that standard, and that may be enough for Postgres 13. But I am concerned that an uncomfortably large proportion of our users will end up needing this. (Perhaps I should say a large proportion of the subset of users that might be affected either way. You get the idea.) I have to wonder if this escape hatch is an escape hatch for our users, or an escape hatch for us. There is a difference. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: