Re: Add mention of execution time memory for enable_partitionwise_* GUCs
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Dimitrios Apostolou <jimis@gmx.net>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-18T10:28:30Z
Lists: pgsql-hackers
On Thu, Jul 18, 2024 at 3:33 PM David Rowley <dgrowleyml@gmail.com> wrote: > > On Thu, 18 Jul 2024 at 21:24, Ashutosh Bapat > <ashutosh.bapat.oss@gmail.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
Commits
-
Doc: mention executor memory usage for enable_partitionwise* GUCs
- 447e25c04915 12.20 landed
- 5eea78af2d3c 13.16 landed
- 51895d08b41a 14.13 landed
- 27146e79bf03 15.8 landed
- a459e583e06b 16.4 landed
- 3256722d7b7f 17.0 landed
- 057ee9183c21 18.0 landed