RE: Implement UNLOGGED clause for COPY FROM

From: "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>
To: "'David G(dot) Johnston'" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Implement UNLOGGED clause for COPY FROM
Date: 2020-07-10 13:38:40
Message-ID: OSBPR01MB48884832932F93DAA953CEB9ED650@OSBPR01MB4888.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2020-07-10 13:43:51 Re: Default setting for enable_hashagg_disk
Previous Message Fabien COELHO 2020-07-10 13:36:07 Re: pgbench - add pseudo-random permutation function