Re: Move pg_attribute.attcompression to earlier in struct for reduced size?

On Fri, Jun 04, 2021 at 07:21:11PM -0400, Alvaro Herrera wrote:
> On 2021-Jun-04, Tom Lane wrote:
> 
> > Alvaro Herrera <alvherre@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+IDnFhwIp@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/YLm5I9MCGz4SnPdX@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