Re: Disable WAL logging to speed up data loading - Mailing list pgsql-hackers

From David Steele
Subject Re: Disable WAL logging to speed up data loading
Date
Msg-id c3b64bb9-5108-796b-93db-96d2cee0c3a2@pgmasters.net
Whole thread Raw
In response to RE: Disable WAL logging to speed up data loading  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Responses RE: Disable WAL logging to speed up data loading  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
List pgsql-hackers
On 1/17/21 12:16 AM, tsunakawa.takay@fujitsu.com wrote:
> From: Osumi, Takamichi/大墨 昂道 <osumi.takamichi@fujitsu.com>
>> I updated my patch to take in those feedbacks !
>> Have a look at the latest patch.
> 
> Looks good to me (the status remains ready for committer.)

After reading through the thread (but not reading the patch) I am -1 on  
this proposal.

The feature seems ripe for abuse and misunderstanding, and as has been  
noted in the thread, there are a variety of alternatives that can  
provide a similar effect.

It doesn't help that at several points along the way new WAL records  
have been found that still need to be included even when wal_level =  
none. It's not clear to me how we know when we have found them all.

The patch is marked Ready for Committer but as far as I can see there  
are no committers in favor of it and quite a few who are not.

Perhaps it would be better to look at some of the more targeted  
approaches mentioned in the thread and see if any of them can be  
used/improved to achieve the desired result?

Regards,
-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: cleanup temporary files after crash
Next
From: Fujii Masao
Date:
Subject: Re: fdatasync performance problem with large number of DB files