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-30 09:12:11 |
Message-ID: | CAExHW5tVskQDGDeY__oV-dZdg13dW3esTawmee3VfwRmGQ-R9w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 29, 2024 at 10:37 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Fri, 19 Jul 2024 at 17:24, Ashutosh Bapat
> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> > I am fine if we want to mention that the executor may consume a large
> > amount of memory when these GUCs are turned ON. Users may decide to
> > turn those OFF if they can not afford to spend that much memory during
> > execution. But I don't like tying execution time consumption with
> > default OFF.
>
> Would the attached address your concern about the reasons for defaulting to off?
Thanks. This looks better. Nitpick
+ child partitions. With this setting enabled, the number of executor
+ nodes whose memory usage is restricted by <varname>work_mem</varname>
This sentence appears to say that the memory usage of "all" nodes is
restricted by work_mem. I think what you want to convey is - nodes,
whose memory usage is subjected to <varname>work_mem</varname>
setting, ....
Or break it into two sentences
With this setting enabled, the number of executor nodes appearing in
the final plan can increase linearly proportional to the number of
partitions being scanned. Each of those nodes may use upto
<varname>work_mem</varname> memory. This can ...
I note that the work_mem documentation does not talk about executor
nodes, instead it uses the term "query operations".
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey M. Borodin | 2024-07-30 09:39:44 | Re: WIP: parallel GiST index builds |
Previous Message | Aleksander Alekseev | 2024-07-30 09:06:29 | Re: Is *fast* 32-bit support still important? |