From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Dimitrios Apostolou <jimis(at)gmx(dot)net>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add mention of execution time memory for enable_partitionwise_* GUCs |
Date: | 2024-07-18 10:28:30 |
Message-ID: | CAExHW5ua8VxBwhySGSJwrhGSJntTf1BPZHhP6F3H74mKfvfDEw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 18, 2024 at 3:33 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Thu, 18 Jul 2024 at 21:24, Ashutosh Bapat
> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> > If those GUCs are enabled, the planner consumes large amount of memory
> > and also takes longer irrespective of whether partitionwise plan is
> > used or not. That's why the default is false. If majority of those
> > joins use nested loop memory, or use index scans instead sorting,
> > memory consumption won't be as large. Saying that it "can" result in
> > large increase in execution memory is not accurate. But I agree that
> > we need to mention the effect of work_mem on partitionwise
> > join/aggregation.
>
> hmm? please tell me what word other than "can" best describes
> something that is possible to happen but does not always happen under
> all circumstances.
May I suggest "may"? :) [1], [2], [3].
My point is, we need to highlight the role of work_mem. So modify both
the descriptions.
[1] https://www.thesaurus.com/e/grammar/can-vs-may/
[2] https://www.britannica.com/dictionary/eb/qa/modal-verbs-may-might-can-could-and-ought
[3] https://www.merriam-webster.com/grammar/when-to-use-can-and-may
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiro.Ikeda | 2024-07-18 10:37:42 | RE: Showing applied extended statistics in explain Part 2 |
Previous Message | Michael Banck | 2024-07-18 10:25:55 | Re: Set log_lock_waits=on by default |