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 TYAPR01MB2990894C2F5FCAECAD837DADFEE80@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Disable WAL logging to speed up data loading  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Disable WAL logging to speed up data loading  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
> Thanks!  Since this feature is different from the feature that is
> being proposed in this thhead, I started another thread for this
> feature.
>
> https://www.postgresql.org/message-id/20201111.173317.460890039962481
> 381.horikyota.ntt@gmail.com

Thank you, Horiguchi-san(^^)  I was just about to ask you to separate the thread, because I think both features are
good:

* ALTER TABLE SET UNLOGGED/LOGGED without data copy
Good:
- Does not require server restart (if this feature can be used in all wal_level settings).

Bad:
- The user has to maintain and modify some scripts to use ALTER TABLE when adding or removing the tables/partitions to
loaddata into.  For example, if the data loading job specifies a partitioned table, he may forget to add ALTER TABLE
fornew partitions, resulting in slow data loading. 


* wal_level = none
Good:
- Easy to use.  The user does not have to be aware of what tables are loaded.  This can come in handy when migrating
froman older version or another DBMS, building test databases, and consolidating databases. 

Bad:
- Requires server restart.


* Both features
Bad:
- Requires taking database backup.
- Requires rebuilding the standby.


Sadly, the new thread's title includes a spelling mistake of extra r -- "In-placre".  (I hope this won't prevent the
searchhit in the mail archive.) 

I expect both features will be able to meet our customer's needs.  The worst scenario (I don't want to imagine!) is
thatneither feature fails to be committed.  So, let us continue both features.  I'll join Horiguchi-san's new thread,
andplease help us here too.  (I'll catch up with the recent discussion in this thread and reply.) 


> Couldn't we have something like the following?
>
>  ALTER TABLE table1, table2, table3 SET UNLOGGED;
>
> That is, multiple target object specification in ALTER TABLE sttatement.

Likewise, can't we do ALTER TABLE SET UNLOGGED/LOGGED against a partitioned table?  Currently, the statement succeeds
butnone of the partitioned table nor its partitions is set unlogged (pg_class.relpersistence remains 'p').  Is this
intended? If it's a bug, I'm willing to fix it so that it reports an eror.  Of course, it's good to make all partitions
unloggedat once. 


Regards
Takayuki Tsunakawa




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Clean up optional rules in grammar
Next
From: Amit Langote
Date:
Subject: Re: ModifyTable overheads in generic plans