Re: Move pg_attribute.attcompression to earlier in struct for reduced size? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Date
Msg-id 1683251.1622083422@sss.pgh.pa.us
Whole thread Raw
In response to Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Andres Freund <andres@anarazel.de>)
Responses Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> That's not *too* bad, but also not nothing....

The memsets seem to be easy to get rid of.  memset the array
to zeroes *once* before entering the per-tuple loop.  Then,
in the loop that looks for stuff to pfree, reset any entries
that are found to be set, thereby returning the array to all
zeroes for the next iteration.

I"m having a hard time though believing that the memset is the
main problem.  I'd think the pfree search loop is at least as
expensive.  Maybe skip that when not useful, by having a single
bool flag remembering whether any columns got detoasted in this
row?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Skip partition tuple routing with constant partition key