Re: Increase of maintenance_work_mem limit in 64-bit Windows - Mailing list pgsql-hackers

From David Rowley
Subject Re: Increase of maintenance_work_mem limit in 64-bit Windows
Date
Msg-id CAApHDvpVqZ=HRvOVv=1TLhH1Gs_-H+b2YTZX0-Tzgz1bbpafVw@mail.gmail.com
Whole thread Raw
In response to Re: Increase of maintenance_work_mem limit in 64-bit Windows  (Vladlen Popolitov <v.popolitov@postgrespro.ru>)
Responses Re: Increase of maintenance_work_mem limit in 64-bit Windows
List pgsql-hackers
On Tue, 24 Sept 2024 at 02:47, Vladlen Popolitov
<v.popolitov@postgrespro.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



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Using per-transaction memory contexts for storing decoded tuples
Next
From: David Rowley
Date:
Subject: Re: Why don't we consider explicit Incremental Sort?