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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Date: 2021-05-27 01:00:16
Message-ID: YK7vIBv+DDaQuebf@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 26, 2021 at 08:35:46PM -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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?

Andres' point is that we'd still initialize and run through
values_free at the end of reform_and_rewrite_tuple() for each tuple
even if there no need to do so. Well, we could control the
initialization and the free() checks at the end of the routine if we
know that there has been at least one detoasted value, at the expense
of making the code a bit less clear, of course.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message tanghy.fnst@fujitsu.com 2021-05-27 01:20:25 RE: [HACKERS] logical decoding of two-phase transactions
Previous Message Kyotaro Horiguchi 2021-05-27 00:49:14 Re: Race condition in recovery?