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

From Alvaro Herrera
Subject Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Date
Msg-id 202106081439.m2pwwk5yvcrd@alvherre.pgsql
Whole thread Raw
In response to Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
List pgsql-hackers
On 2021-Jun-06, Michael Paquier wrote:

> On Fri, Jun 04, 2021 at 07:21:11PM -0400, Alvaro Herrera wrote:

> 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.

Hmm, ok.  Trying to figure out what is happening would require more time
than I can devote to this at present.

My unverified guess is that this code causes too many pipeline stalls
while executing the big per-column loop.  Maybe it would be better to
scan the attribute array twice: one to collect all data from
Form_pg_attribute for each column into nicely packed arrays, then in a
second loop process all the recompressions together ... the idea being
that the first loop can run without stalling.

Maybe at this point reverting is the only solution.

-- 
Álvaro Herrera                            39°49'30"S 73°17'W
"Oh, great altar of passive entertainment, bestow upon me thy discordant images
at such speed as to render linear thought impossible" (Calvin a la TV)



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Misplaced superuser check in pg_log_backend_memory_contexts()
Next
From: Robert Haas
Date:
Subject: Re: [bug?] Missed parallel safety checks, and wrong parallel safety