Re: Making aggregate deserialization (and WAL receive) functions slightly faster
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2023-10-05T05:23:36Z
Lists: pgsql-hackers
On Wed, Oct 04, 2023 at 07:47:11PM +1300, David Rowley wrote: > The original patch had a new function in stringinfo.c which allowed a > StringInfoData to be initialised from an existing string with some > given length. Tom wasn't a fan of that because there wasn't any > protection against someone trying to use the given StringInfoData and > then calling appendStringInfo to append another string. That can't be > done in this case as we can't repalloc the VARDATA_ANY(state) pointer > due to it not pointing directly to a palloc'd chunk. Tom's complaint > seemed to be about having a reusable function which could be abused, > so I modified the patch to remove the reusable code. I think your > macro idea in stringinfo.h would put the patch in the same position as > it was initially. Ahem, well. Based on this argument my own argument does not hold much. Perhaps I'd still use a macro at the top of array_userfuncs.c and numeric.c, to avoid repeating the same pattern respectively two and four times, documenting once on top of both macros that this is a fake StringInfo because of the reasons documented in these code paths. -- Michael
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