From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Robert Haas <robertmhaas@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>,
        Michael Paquier <michael@paquier.xyz>,
        Andres Freund <andres@anarazel.de>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced
 size?
In-reply-to: <202105271934.mneyybkyeo66@alvherre.pgsql>
References: <202105271934.mneyybkyeo66@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Thu, 27 May 2021 15:34:21 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1885749.1622146678.1@sss.pgh.pa.us>
Date: Thu, 27 May 2021 16:17:58 -0400
Message-ID: <1885750.1622146678@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1885750.1622146678%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> 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.

BTW, perhaps I should clarify my goal here: it's to cut off expending
further effort on this feature during v14.  If we can decide that the
existing performance situation is acceptable, I'm content with that
decision.  But if we're to start designing new user-visible behavior to
satisfy performance objections, then I'd prefer to remove this VACUUM
behavior altogether for now.

			regards, tom lane