RE: Disable WAL logging to speed up data loading

Поиск
Список
Период
Сортировка
От tsunakawa.takay@fujitsu.com
Тема RE: Disable WAL logging to speed up data loading
Дата
Msg-id TYAPR01MB2990894C2F5FCAECAD837DADFEE80@TYAPR01MB2990.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Disable WAL logging to speed up data loading  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: Disable WAL logging to speed up data loading
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Clean up optional rules in grammar
Следующее
От: Amit Langote
Дата:
Сообщение: Re: ModifyTable overheads in generic plans