Re: alter table xxx set unlogged take long time

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: "James Pang (chaolpan)" <chaolpan(at)cisco(dot)com>, Jim Mlodgenski <jimmy76(at)gmail(dot)com>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: alter table xxx set unlogged take long time
Date: 2022-07-27 14:46:23
Message-ID: 2883168.1658933183@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Joe Conway <mail(at)joeconway(dot)com> writes:
> Then (completely untested) I *think* you could create the "partition"
> initially as a free standing unlogged table, load it, index it, switch
> to logged, and then attach it to the partitioned table.

I'm still of the opinion that this plan to load the data unlogged
and switch to logged later is a loser. Sooner or later you have
got to write the data to WAL, and this approach doesn't eliminate
that cost. What it does do is create one whole extra cycle of
writing the data to disk and reading it back. I don't think
it's an oversight that no such thing is suggested in our standard
tips for bulk-loading data:

https://www.postgresql.org/docs/current/populate.html

What perhaps *is* an oversight is that we don't suggest
use of COPY FREEZE there. AFAIK that doesn't reduce the initial
data loading cost directly, but it would save overhead later.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Joe Conway 2022-07-27 15:01:33 Re: alter table xxx set unlogged take long time
Previous Message Joe Conway 2022-07-27 14:35:02 Re: alter table xxx set unlogged take long time