[>] unlogged temporary table can’t be inherited over sessions first of all.
And unlogged table needs to be recreated due to startup truncation of the table’s content
when the server crashes.
If you hold massive data in an unlogged table,
you’d forced to spend much time to recover it. This isn’t good.
So I’m thinking that COPY UNLOGGED’d provide a more flexible way for keeping data
for COPY FROM users.
I’m considering that the feature gives them a choice that during ordinary operation
you can keep WAL logging for a target table and when you need high-speed loading
you can bypass WAL generation for it.
To achieve this, we have to
consider a new idea like loaded data’d be added
at the end of the all other pages and detach those
if the server crashes during the UNLOGGED loading processing for example.
By the way, “ALTER TABLE tbl SET UNLOGGED” is supported by postgres.
You may think it’s OK to change LOGGED table to UNLOGGED table by this command.
But, it copies the whole relation once actually. (This isn’t written in the manual.)
So this command becomes slow if the table the command is applied to contains a lot of data.
Thus changing the table’s status of UNLOGGED/LOGGED also requires cost at the moment and I think this copy is an obstacle for switching that table’s status.
The discussion of the reason is written in the url below.
https://www.postgresql.org/message-id/flat/CAFcNs%2Bpeg3VPG2%3Dv6Lu3vfCDP8mt7cs6-RMMXxjxWNLREgSRVQ%40mail.gmail.com
Best
Takamichi Osumi
