Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
От | Alvaro Herrera |
---|---|
Тема | Re: Move pg_attribute.attcompression to earlier in struct for reduced size? |
Дата | |
Msg-id | 202106081439.m2pwwk5yvcrd@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Move pg_attribute.attcompression to earlier in struct for reduced size? (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
|
Список | 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 по дате отправления: