Date: Thu, 27 May 2021 11:07:53 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Dilip Kumar <dilipbalaut@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>,
	Robert Haas <robertmhaas@gmail.com>
Subject: Re: Move pg_attribute.attcompression to earlier in struct for
 reduced size?
Message-ID: <YK7++YoPYbsHOb+W@paquier.xyz>
References: <3962395.1621609263@sss.pgh.pa.us>
 <20210521211929.pcehg6f23icwstdb@alap3.anarazel.de>
 <YKsm7qkz+Cq3C3mr@paquier.xyz>
 <CAFiTN-uLQCRLatapZhEaNGH9njY=LndyXJux7H9YCfT9RcE7gA@mail.gmail.com>
 <YKtpZI4PBpVG3ryH@paquier.xyz>
 <CAFiTN-vpHrCzdeyKxpoPViyJCZZx-h8KghQJFyxZd7+Dys6Cow@mail.gmail.com>
 <YKyPM6UC+tBHEuxo@paquier.xyz>
 <20210527003144.xxqppojoiwurc2iz@alap3.anarazel.de>
 <1677691.1622075746@sss.pgh.pa.us>
 <20210527015415.ctuj4yrwnjip5kve@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="rUb6QZ3L6lm2/JA0"
Content-Disposition: inline
In-Reply-To: <20210527015415.ctuj4yrwnjip5kve@alap3.anarazel.de>
Archived-At: 
 <https://www.postgresql.org/message-id/YK7%2B%2BYoPYbsHOb%2BW%40paquier.xyz>
Precedence: bulk


--rUb6QZ3L6lm2/JA0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, May 26, 2021 at 06:54:15PM -0700, Andres Freund wrote:
> Oh, it'll definitely be more expensive in that case - but that seems
> fair game. What I was wondering about was whether VACUUM FULL would be
> measurably slower, because we'll now call toast_get_compression_id() on
> each varlena datum. It's pretty easy for VACUUM FULL to be CPU bound
> already, and presumably this'll add a bit.

This depends on the number of attributes, but I do see an extra 0.5%
__memmove_avx_unaligned_erms in reform_and_rewrite_tuple() for a
normal VACUUM FULL with a 1-int-column relation on a perf profile,
with rewrite_heap_tuple eating most of it as in the past, so that's
within the noise bandwidth if you measure the runtime.  What would be
the worst case here, a table with one text column made of non-NULL
still very short values?
--
Michael

--rUb6QZ3L6lm2/JA0
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmCu/vkACgkQnvQgOdby
QH1qeA/8D+02I7lOYrCkVJtA0DpTbEbocv8O0O0eHV6MNnRRUz868Ogrtlffn+GT
akPs0g7qkV2bv4srVUQcIyn0ide6hbup2Hs8q7D76aOdlJfIcX3E0Cdt7h0Z9tGv
5vKiRqaJEVAMprdrAtBcaljqt+BTdKdhB15lRWJUWUkT2DQB/XkLW2hIaayy0zDu
I8b1vPB7NOKQjMcBNpRVmuPtbTIQs5lfjPQ+zXujcCRxHTQRv8C23TL5dUpfr5Dy
UFk5UijHVvUJjODTsoOU01TMY8RVky+Fxdel033EJxICut49sQ/hEYdNNi7/0VgE
BYZ7ffpoXsXgtRp2sg/r3aHeF8Z5RG2ymyU9TgygD/4C1RZBWU5e5nMBdzu5fUdZ
UfGPoQiG6FTaPZHosdRs/j+Lzk2i7bawjd0Y2PaZg5mKNDVFcD9a8QKECNuYmNbq
5f3Yi/ZRmDJVOAu4nFc5MTmCyT6tHoLbYh2VZoFUz2D7SLCq9W31HeRO1nbtmMV2
s2tDo1NOo+vwKJrzYSTuAgS48o8iISHO196VWSM5jhi9HH+3NbtH4htNy/g9O1WR
9utC7JhLqRzXAVcSeXOrYaP5KIk5Uv9qopeLMYujWdl80YM+5jathXZteM9/R4cX
QIgArGAYznTqzrwWmanOPqqw0S6b5uOEOioAm199dVbVNigQbhI=
=aTBA
-----END PGP SIGNATURE-----

--rUb6QZ3L6lm2/JA0--