Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oGiXd-0001Sq-KF for pgsql-performance@arkaria.postgresql.org; Wed, 27 Jul 2022 15:01:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oGiXc-0005np-F1 for pgsql-performance@arkaria.postgresql.org; Wed, 27 Jul 2022 15:01:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oGiXc-0005ng-5H for pgsql-performance@lists.postgresql.org; Wed, 27 Jul 2022 15:01:40 +0000 Received: from mail-vs1-xe2a.google.com ([2607:f8b0:4864:20::e2a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oGiXZ-00036P-Cx for pgsql-performance@lists.postgresql.org; Wed, 27 Jul 2022 15:01:39 +0000 Received: by mail-vs1-xe2a.google.com with SMTP id 125so16851227vsx.7 for ; Wed, 27 Jul 2022 08:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joeconway.com; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=z2XgpOyA7fepCJHbLiVYyWZ3j50j5jXxhP7KV6OQAT4=; b=pMmMqOPGToIMMMH0S9EPQtrxIGjXrGZ8N/5FbSBi8X75zLKkjteKd/XGHnmPhgWKpZ +v18+txE+kzXEv3jADSNFyrakvJR1WrPnTsG3w9LNhlzSBvozUhtSQJF8A23W+ZXA9sW wP36Lj/6hb0jp19zYgjS5y/zZnhWyX6Dlv1aPUfIIyAaQwuOLxrVeG7u7VkYUVyhRgmR CvBSzpV6PIY6CzxlOho/pdCj6PRzb4Plwusine0O+lgUDzEFU2CgpuLbLygvkd2IBHuP zm51dFArwVj0JZFDiHm4KylKX77cmM/Mg3DomYa9AzS7hKuK4UTyTZvvz6SyffDH3puA wPVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=z2XgpOyA7fepCJHbLiVYyWZ3j50j5jXxhP7KV6OQAT4=; b=28zO98An1/XxMEbVIZS/zbPg9CI6SG44qx2ko7/O3JZv9CewGsQYN02/DzFkZA81Em y5A6kxJodP+vQdLUV7vzaDDzrdT+s1a7m4Hmu3iSZkEH7Zrex1JAYiIfcCww63LlNi+n gUxdhUg7nt/B/ViyD+6ldfbaceu4K5ifL3pSFsFTTWOHkuwZ99sPFx4H1nLc4LC6jdGU gzoCTpLDpwe7PaUQ6MV7vBY7P2L8Lo8tRupMWdGT5Gah4cImKjmCGrG3jtfUVwz98VxM 6d5tzaNORs1dSf7ZehcnpE/LAgu5Rq0g0ga4pNi3RFEAxBMXp86YGOi7UmRv6jBm5olX PXjw== X-Gm-Message-State: AJIora+i97h9dSrQKtw9VRqsU5oWg7aJUrDt5yagyqTy3l4AzzZlzuXv FlWRPB18K4xtEMMMU6Fw6Zul2Q== X-Google-Smtp-Source: AGRyM1uSaTZrnjQDrCwQCcWk6HsRrVJIBk+ofrzwKThfbaYaaeVi13RDzgJmQmYpeogQRUL10f72QQ== X-Received: by 2002:a67:ca87:0:b0:358:5a89:b2c0 with SMTP id a7-20020a67ca87000000b003585a89b2c0mr5034227vsl.60.1658934095564; Wed, 27 Jul 2022 08:01:35 -0700 (PDT) Received: from [192.168.4.41] (072-017-018-098.res.spectrum.com. [72.17.18.98]) by smtp.gmail.com with ESMTPSA id m25-20020a67f719000000b003584eb295cfsm2346215vso.19.2022.07.27.08.01.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Jul 2022 08:01:35 -0700 (PDT) Message-ID: Date: Wed, 27 Jul 2022 11:01:33 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: alter table xxx set unlogged take long time Content-Language: en-US To: Tom Lane Cc: "James Pang (chaolpan)" , Jim Mlodgenski , "pgsql-performance@lists.postgresql.org" References: <2240967.1658839372@sss.pgh.pa.us> <2883168.1658933183@sss.pgh.pa.us> From: Joe Conway In-Reply-To: <2883168.1658933183@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 7/27/22 10:46, Tom Lane wrote: > Joe Conway 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