Hi, On 2021-05-26 18:54:15 -0700, Andres Freund wrote: > On 2021-05-26 20:35:46 -0400, Tom Lane wrote: > > Andres Freund <and...@anarazel.de> writes: > > > The efficiency bit is probably going to be swamped by the addition of > > > the compression handling, given the amount of additional work we're now > > > doing in in reform_and_rewrite_tuple(). > > > > Only if the user has explicitly requested a change of compression, no? > > 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. >
CREATE UNLOGGED TABLE vacme_text(t01 text not null default 't01',t02 text not null default 't02',t03 text not null default 't03',t04 text not null default 't04',t05 text not null default 't05',t06 text not null default 't06',t07 text not null default 't07',t08 text not null default 't08',t09 text not null default 't09',t10 text not null default 't10'); CREATE UNLOGGED TABLE vacme_int(i1 int not null default '1',i2 int not null default '2',i3 int not null default '3',i4 int not null default '4',i5 int not null default '5',i6 int not null default '6',i7 int not null default '7',i8 int not null default '8',i9 int not null default '9',i10 int not null default '10'); INSERT INTO vacme_text SELECT FROM generate_series(1, 10000000); INSERT INTO vacme_int SELECT FROM generate_series(1, 10000000); I ran 10 VACUUM FULLs on each, chose the shortest time: unmodified text: 3562ms int: 3037ms after ifdefing out the compression handling: text: 3175ms (x 0.88) int: 2894ms (x 0.95) That's not *too* bad, but also not nothing.... Greetings, Andres Freund
