On Wed, 31 Jul 2024 at 16:15, Ashutosh Bapat
wrote:
> We can commit your
> version and see if users find it confusing.
Ok. I've now pushed the patch. Thanks for reviewing it.
David
On Tue, Jul 30, 2024 at 5:38 PM David Rowley wrote:
>
> On Tue, 30 Jul 2024 at 21:12, Ashutosh Bapat
> wrote:
> > Thanks. This looks better. Nitpick
> >
> > +child partitions. With this setting enabled, the number of
> > executor
> > +nodes whose memory usage is restricted by
>
On Tue, 30 Jul 2024 at 21:12, Ashutosh Bapat
wrote:
> Thanks. This looks better. Nitpick
>
> +child partitions. With this setting enabled, the number of executor
> +nodes whose memory usage is restricted by work_mem
>
> This sentence appears to say that the memory usage of "all" n
On Mon, Jul 29, 2024 at 10:37 AM David Rowley wrote:
>
> On Fri, 19 Jul 2024 at 17:24, Ashutosh Bapat
> 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 affor
On Fri, 19 Jul 2024 at 17:24, Ashutosh Bapat
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 t
Thank you for the patch improving the docs, I think it's a clear
improvement from before.
On Thu, 18 Jul 2024, David Rowley wrote:
I considered writing about work_mem, but felt I wanted to keep it as
brief as possible and just have some words that might make someone
think twice. The details in
On Fri, 19 Jul 2024 at 17:24, Ashutosh Bapat
wrote:
> According to [1] these GUCs were added because of increased
> memory consumption during planning and time taken to plan the query.
> The execution time memory consumption issue was known even back then
> but the GUC was not set to default becau
On Thu, Jul 18, 2024 at 4:24 PM David Rowley wrote:
>
> On Thu, 18 Jul 2024 at 22:28, Ashutosh Bapat
> wrote:
> >
> > On Thu, Jul 18, 2024 at 3:33 PM David Rowley wrote:
> > > hmm? please tell me what word other than "can" best describes
> > > something that is possible to happen but does not al
On Thu, 18 Jul 2024 at 22:28, Ashutosh Bapat
wrote:
>
> On Thu, Jul 18, 2024 at 3:33 PM David Rowley wrote:
> > 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"? :
On Thu, Jul 18, 2024 at 3:33 PM David Rowley wrote:
>
> On Thu, 18 Jul 2024 at 21:24, Ashutosh Bapat
> 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
On Thu, 18 Jul 2024 at 21:24, Ashutosh Bapat
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
On Thu, Jul 18, 2024 at 4:03 AM David Rowley wrote:
>
> Over on [1], there's a complaint about a query OOMing because the use
> of enable_partitionwise_aggregate caused a plan with 1000 Hash
> Aggregate nodes.
>
> The only mention in the docs is the additional memory requirements and
> CPU for que
Over on [1], there's a complaint about a query OOMing because the use
of enable_partitionwise_aggregate caused a plan with 1000 Hash
Aggregate nodes.
The only mention in the docs is the additional memory requirements and
CPU for query planning when that GUC is enabled. There's no mention
that exec
13 matches
Mail list logo
