Re: Disable WAL logging to speed up data loading
| От | Kyotaro Horiguchi |
|---|---|
| Тема | Re: Disable WAL logging to speed up data loading |
| Дата | |
| Msg-id | 20201002.140752.958558461530383405.horikyota.ntt@gmail.com обсуждение исходный текст |
| Ответ на | Re: Disable WAL logging to speed up data loading (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
| Список | pgsql-hackers |
At Fri, 02 Oct 2020 13:51:35 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > Sorry for the slippery brain... ^2 > At Fri, 02 Oct 2020 13:38:22 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > > At Fri, 2 Oct 2020 10:56:21 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in > > > > > > On 2020/10/02 10:06, Kyotaro Horiguchi wrote: > > > > 1. Flip BM_PERMANENT of active buffers > > > > 2. adding/removing init fork > > > > 3. sync files, > > > > 4. Flip pg_class.relpersistence. > > > > It always skips table copy in the SET UNLOGGED case, > > > > > > Even in wal_level != minimal? > > > What happens in the standby side when SET UNLOGGED is executed without > > > the table rewrite in the primary? The table data should be truncated > > > in the standby? > > > > A table turned into unlogged on the primary is also turned into > > unlogged on the standby and it is inaccessible on the standby. > Maybe the storage dropped on unpatched Maybe the old storage is replaced with an empty stroage on unpatched. > and left alone on patched. > > After the table is again turned into logged, the content is > > transferred via WAL records generated from the insertions into the new > > storage and it rebuilds the same storage on the standby on both > > patched and unpatched. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: