Re: Implement UNLOGGED clause for COPY FROM

Поиск
Список
Период
Сортировка
От Peter Smith
Тема Re: Implement UNLOGGED clause for COPY FROM
Дата
Msg-id CAHut+PusrZun7KZjgsgDw8N-+h54npF88LPhcnPZSURwsrzL2A@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Implement UNLOGGED clause for COPY FROM  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Ответы RE: Implement UNLOGGED clause for COPY FROM
Список pgsql-hackers
Hi.

I expect I have some basic misunderstanding because IMO now this
thread seems to have come full circle.

Earlier, Osumi-san was rejecting the idea of using ALTER TABLE tbl SET
UNLOGGED on basis that it is too time consuming for large data to
switch the table modes [1].

Now the latest idea is to introduce a wal_level=none. But now
apparently full daily backups are OK, and daily restarting the server
before the copies is also OK [2].

~

Doesn't wal_level=none essentially just behave as if every table was
UNLOGGED; not just the ones we are loading?

Doesn't wal_level=none come with all the same limitations/requirements
(full daily backups/restarts etc) that the UNLOGGED TABLE would also
have?

So I don't recognise the difference?

If wal_level=none is judged OK as a fast loading solution, then why
wasn't an initially UNLOGGED table also judged OK by the same
criteria? And if there is no real difference, then why is it necessary
to introduce wal_level=none (instead of using the existing UNLOGGED
feature) in the first place?

Or, if all this problem is simply due to a quirk that the BI tool
referred to does not support the CREATE UNLOGGED TABLE syntax [3],
then surely there is some other workaround could be written to handle
that.

What part am I missing?

--
[1] -
https://www.postgresql.org/message-id/OSBPR01MB48884832932F93DAA953CEB9ED650%40OSBPR01MB4888.jpnprd01.prod.outlook.com
[2] -
https://www.postgresql.org/message-id/TYAPR01MB299005FC543C43348A4993FDFE550%40TYAPR01MB2990.jpnprd01.prod.outlook.com
[3] -
https://www.postgresql.org/message-id/OSBPR01MB4888CBD08DDF73721C18D2C0ED790%40OSBPR01MB4888.jpnprd01.prod.outlook.com

Kind Regards,
Peter Smith.
Fujitsu Australia



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Zidenberg, Tsahi"
Дата:
Сообщение: Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: doc review for v13