Re: Default setting for enable_hashagg_disk
От | Tom Lane |
---|---|
Тема | Re: Default setting for enable_hashagg_disk |
Дата | |
Msg-id | 2165606.1594418399@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Default setting for enable_hashagg_disk (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Default setting for enable_hashagg_disk
Re: Default setting for enable_hashagg_disk Re: Default setting for enable_hashagg_disk |
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.net> writes: > I don't see hash_mem as being any kind of proper fix- it's just punting > to the user saying "we can't figure this out, how about you do it" and, > worse, it's in conflict with how we already ask the user that question. > Turning it into a multiplier doesn't change that either. Have you got a better proposal that is reasonably implementable for v13? (I do not accept the argument that "do nothing" is a better proposal.) I agree that hash_mem is a stopgap, whether it's a multiplier or no, but at this point it seems difficult to avoid inventing a stopgap. Getting rid of the process-global work_mem setting is a research project, and one I wouldn't even count on having results from for v14. In the meantime, it seems dead certain that there are applications for which the current behavior will be problematic. hash_mem seems like a cleaner and more useful stopgap than the "escape hatch" approach, at least to me. regards, tom lane
В списке pgsql-hackers по дате отправления: