Re: Making aggregate deserialization (and WAL receive) functions slightly faster
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2023-11-06T22:26:05Z
Lists: pgsql-hackers
On Thu, 2 Nov 2023 at 22:42, Amit Kapila <amit.kapila16@gmail.com> wrote: > The other two look good to me. Thanks for looking. I spent some time trying to see if the performance changes much with either of these cases. For the XLogWalRcvProcessMsg() I was unable to measure any difference even when replaying inserts into a table with a single int4 column and no indexes. I think that change is worthwhile regardless as it allows us to get rid of a global variable. I was tempted to shorten the name of that variable a bit since it's now local, but didn't as it causes a bit more churn. For the apply_spooled_messages() change, I tried logical decoding but quickly saw apply_spooled_messages() isn't the normal case. I didn't quite find a test case that caused the changes to be serialized to a file, but I do see that the number of bytes can be large so thought that it's worthwhile saving the memcpy for that case. I pushed those two changes. David
Commits
-
Make use of initReadOnlyStringInfo() in more places
- ac7d6f5f831e 17.0 landed
-
Optimize various aggregate deserialization functions, take 2
- 0c882a298881 17.0 landed
-
Introduce the concept of read-only StringInfos
- f0efa5aec193 17.0 landed
-
Revert "Optimize various aggregate deserialization functions"
- 4f3b56eea235 17.0 landed
-
Optimize various aggregate deserialization functions
- 608fd198def5 17.0 landed