On Fri, Jun 04, 2021 at 07:21:11PM -0400, Alvaro Herrera wrote: > On 2021-Jun-04, Tom Lane wrote: > > > Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > > > > Now, while this patch does seem to work correctly, it raises a number of > > > weird cpluspluscheck warnings, which I think are attributable to the > > > new macro definitions. I didn't look into it closely, but I suppose it > > > should be fixable given sufficient effort: > > > > Didn't test, but the first one is certainly fixable by adding a cast, > > and I guess the others might be as well. > > I get no warnings with this one. I'm a bit wary of leaving > VARDATA_COMPRESSED_GET_EXTSIZE unchanged, but at least nothing in this > patch requires a cast there.
I have done the same test as previously, with the following configuration to be clear: - No assertion, non-debug build. - No autovacuum. - No recompression involved. - Data put in a tmpfs. - One relation with 200 columns of NOT NULL text with default values, using that: https://postgr.es/m/ylbt02a+idnfh...@paquier.xyz - 1M rows. - 15 VACUUM FULL runs, discarding the 3 lowest and the 3 highest run times to remove most of the noise, then did an average of the remaining 9 runs. The test has been done with four configurations, and here are the results: 1) HEAD: 9659ms 2) REL_13_STABLE: 8310ms. 3) Alvaro's patch, as of https://postgr.es/m/202106042321.6jx54yliy2l6@alvherre.pgsql: 9521ms. 4) My patch applied on HEAD, as of https://postgr.es/m/ylm5i9mcgz4sn...@paquier.xyz: 8304ms. This case is a kind of worst-case configuration, but it seems to me that there is still a large difference with that :/ -- Michael
signature.asc
Description: PGP signature
