Re: Add mention of execution time memory for enable_partitionwise_* GUCs

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

In response to

Responses

Browse pgsql-hackers by date

  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?