Re: Increase of maintenance_work_mem limit in 64-bit Windows

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Increase of maintenance_work_mem limit in 64-bit Windows
Date: 2024-09-23 22:07:23
Message-ID: CAApHDvpVqZ=HRvOVv=1TLhH1Gs_-H+b2YTZX0-Tzgz1bbpafVw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 24 Sept 2024 at 02:47, Vladlen Popolitov
<v(dot)popolitov(at)postgrespro(dot)ru> wrote:
> I agree, it is better to fix all them together. I also do not like this
> hack, it will be removed from the patch, if I check and change
> all <work_mem_vars> at once.
> I think, it will take about 1 week to fix and test all changes. I will
> estimate the total volume of the changes and think, how to group them
> in the patch ( I hope, it will be only one patch)

There's a few places that do this:

Size maxBlockSize = ALLOCSET_DEFAULT_MAXSIZE;

/* choose the maxBlockSize to be no larger than 1/16 of work_mem */
while (16 * maxBlockSize > work_mem * 1024L)

I think since maxBlockSize is a Size variable, that the above should
probably be:

while (16 * maxBlockSize > (Size) work_mem * 1024)

Maybe there can be a precursor patch to fix all those to get rid of
the 'L' and cast to the type we're comparing to or assigning to rather
than trying to keep the result of the multiplication as a long.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2024-09-23 22:21:58 Re: Why don't we consider explicit Incremental Sort?
Previous Message Masahiko Sawada 2024-09-23 21:36:09 Re: Using per-transaction memory contexts for storing decoded tuples