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
signature.asc
Description: PGP signature
