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

From tsunakawa.takay@fujitsu.com
Subject RE: Disable WAL logging to speed up data loading
Date
Msg-id TYAPR01MB299062D951F926DF80D25C4CFE689@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Disable WAL logging to speed up data loading  (David Steele <david@pgmasters.net>)
Responses Re: Disable WAL logging to speed up data loading
Re: Disable WAL logging to speed up data loading
List pgsql-hackers
From: David Steele <david@pgmasters.net>
> 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.

I can understand that people are worried about not having WAL.  But as far as I remember, I'm afraid those concerns
wereemotional, not logical, i.e., something like "something may happen.".  Regarding concrete concerns that
Stephen-san,Magnus-san, Horiguchi-san, Sawada-san and others raised, Osumi-san addressed them based on their advice and
review,both in this thread and other threads. 

I also understand we want to value people's emotion for worry-free PostgreSQL.  At the same time, I'd like the emotion
understoodthat we want Postgres to have this convenient, easy-to-use feature.  MySQL recently introduced this feature.
Whycan't Postgres do it? 


> 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?

Other methods are not as easy-to-use, and more complex to implement.

What kind of destiny does this type of feature end up in?


    Regards
Takayuki Tsunakawa}




pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: [HACKERS] logical decoding of two-phase transactions
Next
From: Peter Eisentraut
Date:
Subject: Re: Allow an alias to be attached directly to a JOIN ... USING