Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
От | Peter Geoghegan |
---|---|
Тема | Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. |
Дата | |
Msg-id | CAH2-Wz=QjO7vGrrZQ3VWsatbujFzmyH4GtBKXFTUpVVCW3RFEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
|
Список | pgsql-hackers |
On Mon, Jul 27, 2020 at 8:36 PM Justin Pryzby <pryzby@telsasoft.com> wrote: > I don't know of a guideline for text format, but the issues I've raised for > HashAgg and IncrSort are based on previous commits which change to "show field > even if its value is zero" for non-text format: But the non-text format for IncrSort shows about the same information as sort, broken out by group. What's missing if you assume that sort is the gold standard? The objection to your argument from James (which could just as easily apply to regular sort from earlier releases) is that accurate information just isn't available as a practical matter. This is due to tuplesort implementation limitations that cannot be fixed now. See the comment block in tuplesort_get_stats() for an explanation. The hard part is showing memory used by external sorts. It's true that "Disk" is specifically shown by sort nodes output in text explain format, but you're talking about non-text formats so that's not really relevant AFAICT sort (and IncrSort) don't fail to show a field value if it is zero. Rather, they consistently show "space used" (in non-text format), which can be either memory or disk space. Technically they don't violate the letter of the law that you cite. (Though admittedly this is a legalistic loophole -- the "space" value presumably has to be interpreted according to different rules for programs that consume non-text EXPLAIN output.) Have I missed something? -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: