Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rz0Aa-001TTC-9z for pgsql-general@arkaria.postgresql.org; Mon, 22 Apr 2024 20:21:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rz0AZ-00FZsO-1J for pgsql-general@arkaria.postgresql.org; Mon, 22 Apr 2024 20:21:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rz0AY-00FZsC-2o for pgsql-general@lists.postgresql.org; Mon, 22 Apr 2024 20:21:42 +0000 Received: from fout8-smtp.messagingengine.com ([103.168.172.151]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rz0AT-002Ols-Q5 for pgsql-general@postgresql.org; Mon, 22 Apr 2024 20:21:41 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfout.nyi.internal (Postfix) with ESMTP id E26A613800C1; Mon, 22 Apr 2024 16:21:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 22 Apr 2024 16:21:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1713817294; x=1713903694; bh=0zZ/OYvjvJsjfz1v2LnXbIHUQhR5HwHGVegnWjQTUBE=; b= UEoDdVj7Fwmm/Wd0zDCebbGqszOpTDRQQ1MVovK8fLd6sdJo64JSr2lfHES+Djtq GO0buM8HroM4RQ2QP6bc/w+EmHOV5uoldmy3O4PuOVSIQeOWtDLWeS0Zg6ieMz5T 5MjeTeNIgFrOVC0AwDKZT8g8xfNnHjtDiX/gHU3ag4tDwViIr8vdTlj+biUKqXEm kuBiLxxfzdU95noCqhUr16MyppUQ1EHo99woVUFCYA69LVv7NCbOrSzOn1AwcDu8 3raq16wT73c6+Z/E/iu6i0pzFEKLQh1k8d9vtma2hUVHMKu8laHVap8R5KKD4gAQ XhVRQXURP6TT/TwjivnDmw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1713817294; x= 1713903694; bh=0zZ/OYvjvJsjfz1v2LnXbIHUQhR5HwHGVegnWjQTUBE=; b=H rcBXhLqSe3MICGxrVMxixhzHKg4eEfXPQ/rm0osPnfHaCz+WRwSwkfoQDa+fMOoQ YwBFZV6aogKTNsrxFR/Hi0gMG3baYxVPBX6ncR21OaeHbKH3SWzQAEzvXgMwg02I /DfcBaAJjjQN6yUk63flhyKbuEPkzsjl0PTZsqduT9xJqe8gW7Lm8B1wQ/mKw31g p9F7p6Ql9Ed95xR+sa4WG+N7e+qc59n/n39fYKsH67tAe9UHnunJ6UwNFPVSmjHt cMZvDb/cXFAmQovAv4y/bhtCvGhPTVEDo7Bpfst07axxNuBca/6HFGdtzb1fyjDo Tx1pzu943PlJydG86ZhJg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudekledgudeglecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvvehfhfgjtgfgse htkeertddtvdejnecuhfhrohhmpeetughrihgrnhcumfhlrghvvghruceorggurhhirghn rdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomheqnecuggftrfgrthhtvghrnhepgfdufe ekhfevfeelveeiueevhedvuddukeduvddvlefhueeuieejtdeuvdevvdeunecuffhomhgr ihhnpehpohhsthhgrhgvshhqlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghr rdgtohhm X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 22 Apr 2024 16:21:34 -0400 (EDT) Message-ID: <4e81951f-4666-400d-b836-a020e55e168a@aklaver.com> Date: Mon, 22 Apr 2024 13:21:33 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: CLUSTER vs. VACUUM FULL To: Ron Johnson Cc: pgsql-general References: <2870091.1713739514@sss.pgh.pa.us> <3043219.1713795953@sss.pgh.pa.us> <632e3176-13e4-4863-b8b9-bc1aba778268@aklaver.com> Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 4/22/24 12:51, Ron Johnson wrote: > On Mon, Apr 22, 2024 at 3:14 PM Adrian Klaver > wrote: > > > > > 1) If they are already in enough of a PK order that the CLUSTER time vs > VACUUM FULL time would not be material as there is not much or any > sorting to do then what does the CLUSTER gain you? > > > Not much.  Now they're just "slightly more ordered" instead of "slightly > less ordered" for little if any extra effort. > > 2) What evidence is there that the records where still in PK order just > because you deleted based on CREATED_ON? I understand the correlation > between CREATED_ON and the PK just not sure why that would necessarily > translate to an on disk order by PK? > > > 1. Records are appended to tables in INSERT order, and INSERT order is > highly correlated to synthetic PK, by the nature of sequences. Not something I would count on, see: https://www.postgresql.org/docs/current/sql-createsequence.html Notes for how that may not always be the case. Also any UPDATE or DELETE is going to change that. There is no guarantee of order for the data in the table. If there where you would not need to run CLUSTER. > 2. My original email showed that CLUSTER took just as long as VACUUM > FULL.  That means not many records had to be sorted, because... the > on-disk order was strongly correlated to PK and CREATED_ON. > > Will that happen *every time* in *every circumstance* in *every > database*?  No, and I never said it would.  But it does in *my *database > in *this *application. > Which gets us back to your comment upstream: "What the VACUUM docs "should" do, it seems, is suggest CLUSTER on the PK, if the PK is a sequence (whether that be an actual sequence, or a timestamp or something else that grows monotonically)." This is a case specific to you and this particular circumstance, not a general rule for VACUUM FULL. If for no other reason then it might make more sense for the application that the CLUSTER be done on some other index then the PK. -- Adrian Klaver adrian.klaver@aklaver.com