Re: alter table xxx set unlogged take long time

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 15:01:33
Message-ID: ffb85e8c-cf2d-0f5a-c805-ad66a5a23601@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 7/27/22 10:46, Tom Lane wrote:
> 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:

Yeah, agreed. I was mostly responding to the OP desire to use unlogged
and not taking a stance on that.

> 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.

Oh, yes, very good point.

--
Joe Conway
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Janes 2022-07-27 17:17:23 Re: Postgresql 14 partitioning advice
Previous Message Tom Lane 2022-07-27 14:46:23 Re: alter table xxx set unlogged take long time