Re: VACUUM memory management - Mailing list pgsql-hackers

From Ibrar Ahmed
Subject Re: VACUUM memory management
Date
Msg-id CALtqXTfaxwF9NxMeADfzeXPWsC+w3Vg0etCfHrRQ-Tqa=GXm2w@mail.gmail.com
Whole thread Raw
In response to Re: VACUUM memory management  (Ibrar Ahmed <ibrar.ahmad@gmail.com>)
Responses RE: VACUUM memory management
Re: VACUUM memory management
List pgsql-hackers


On Wed, Dec 11, 2019 at 9:29 PM Ibrar Ahmed <ibrar.ahmad@gmail.com> wrote:


On Wed, Dec 11, 2019 at 7:29 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Dec 9, 2019 at 2:02 PM Ibrar Ahmed <ibrar.ahmad@gmail.com> wrote:
>> Did you see this thread?
>> https://postgr.es/m/CAGTBQpbDCaR6vv9=scXzuT8fSbckf=a3NgZdWFWZbdVugVht6Q@mail.gmail.com
>>
> Yes, and somehow did what is explained.

Did you modify Claudio's patch or write a totally new one?
 
I wrote completely new patch. I tried multiple techniques like using a list instead of fixed size array which I thought was most suitable here, but leave that because of conflict with Parallel Vacuum. 
 
In either case, why did you choose that approach?
 
This is the simplest technique. I just divided the maintenance_work_mem in chunks and allocate chunks as needed. This technique change minimum code and do what we want to achieve. 
 
If you wrote a totally new one, have you compared your work with Claudio's, to see if he covered
anything you might need to cover?
 
No, this part I missed, I will do that and will share my thoughts.

I checked the patch, and it does not do anything special which my patch is not doing except one thing. The patch is claiming to increase the limit of 1GB along with that, but I have not touched that. In my case, we are still under the limit of maintaines_work_mem but allocate memory in chunks. In that case, you have the leverage to set a big value of maintaness_work_mem (even if you don't need that)  because it will not allocate all the memory at the start. 

Secondly, the patch refactors the whole area of code which makes this patch larger than expected. The code changes in the patch are almost doubled from my patch. By the way, now I took the test cases from the patch and included that into my patch (Credit Claudio) 

 Please explain why your patch is
better/different than his.

 
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--
Ibrar Ahmed


--
Ibrar Ahmed
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: force_parallel_mode = regress has a blind spot
Next
From: David Fetter
Date:
Subject: Re: Make autovacuum sort tables in descending order of xid_age