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

From Andres Freund
Subject Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Date
Msg-id 20210527032105.xistjgattubmjymm@alap3.anarazel.de
Whole thread Raw
In response to Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
List pgsql-hackers
Hi,

On 2021-05-26 22:43:42 -0400, Tom Lane wrote:
> 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?

Yea, I tested that - it does help in the integer case. But the bigger
contributors are the loop over the attributes, and especially the access
to the datum's compression method. Particularly the latter seems hard to
avoid.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Fdw batch insert error out when set batch_size > 65535
Next
From: Amit Kapila
Date:
Subject: Re: Decoding speculative insert with toast leaks memory