Hi David Johnston Thank you for your comment. Aside from that, though, how does this improve upon the existing capability to copy into an unlogged temporary table?
[>] 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
