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 1lmLm7-0001An-35 for pgsql-hackers@arkaria.postgresql.org; Thu, 27 May 2021 19:34:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lmLm5-00075R-Mj for pgsql-hackers@arkaria.postgresql.org; Thu, 27 May 2021 19:34:33 +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 1lmLm4-00075I-Q3 for pgsql-hackers@lists.postgresql.org; Thu, 27 May 2021 19:34:33 +0000 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lmLm1-00076W-Ub for pgsql-hackers@postgresql.org; Thu, 27 May 2021 19:34:32 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 6B69A6BF; Thu, 27 May 2021 15:34:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 27 May 2021 15:34:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=9CrQRQ4d6RTUauOo8UFxBq8B8I7nIwop9b5qIOjCRNE=; b=PnyfcpQe 0POxAWLtz5+WkUqhLwbUrhndcNpc5ESQ7RnnAleWOp5w04QKcriCq4b1MDNbrdlL bl8hCl1oAYOhnyCtRj6mVVqiSitjss8XMhyCGp8+mhQKEhOEm9pN94Ye744QX15h IWABEH2GCSj2KNgyGZ6c/2/g/+1/mEl4TdCB4tSIrUIO22VmKt9MzIUZxS9EDqLd JAxhiEHUdNsXUNrQOR90M5Odh0ad/2kN8xR5xC+jxM4+UwInMWOM8MRT7LkI3kdc tSc8dWveIyyWcPzK+k0qJGK6SbLQYEcaQzb+4Tzc0zRZ7N4oj9Qvr6WWnHeR2ExO FVPlz0+fdUsyvQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdekhedgudegvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtugfgjgesthekredttddtudenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepgeegveevffevjeffudethfdvtdeggefhhffguefhfeej iefgvefhfeelvedtudetnecukfhppeduledtrdelhedrudelrdelheenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghl vhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.95]) by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 May 2021 15:34:24 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 57D7F2A0A8B; Thu, 27 May 2021 15:34:21 -0400 (-04) Date: Thu, 27 May 2021 15:34:21 -0400 From: Alvaro Herrera To: Tom Lane Cc: Robert Haas , Dilip Kumar , Michael Paquier , Andres Freund , pgsql-hackers Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size? Message-ID: <202105271934.mneyybkyeo66@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1719337.1622126391@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-May-27, Tom Lane wrote: > I say it's time to stop the bleeding and rip it out. When and if > there are actual field requests to have a way to do this, we can > discuss what's the best way to respond to those requests. Hacking > VACUUM probably isn't the best answer, anyway. But right now, > we are past feature freeze, and I think we ought to jettison this > one rather than quickly kluge something. Sorry, I'm unclear on exactly what are you proposing. Are you proposing to rip out the fact that VACUUM FULL promises to recompress everything, or are you proposing to rip out the whole attcompression feature? Absolute -1 on the latter from me. Pluggable compression has taken years to get to this point, it certainly won't do to give that up. Now about the former. If we do think that recompressing causes an unacceptable 10% slowdown for every single VACUUM FULLs, then yeah we should discuss changing that behavior -- maybe remove promises of recompression and wait for pg15 to add "VACUUM (RECOMPRESS)" or similar. If it's a 10% slowdown of the only best times (variability unspecified) and only in corner cases (unlogged tables with no indexes that fit in shared buffers), then I don't think we should bother. -- Álvaro Herrera 39°49'30"S 73°17'W "You're _really_ hosed if the person doing the hiring doesn't understand relational systems: you end up with a whole raft of programmers, none of whom has had a Date with the clue stick." (Andrew Sullivan)