On Thu, 14 Dec 2023 at 19:21, Matthias van de Meent <boekewurm+postg...@gmail.com> wrote: > > On Thu, 7 Dec 2023 at 13:09, David Rowley <dgrowle...@gmail.com> wrote: > > We could also easily serialize plans to binary format for copying to > > parallel workers rather than converting them to a text-based > > serialized format. It would also allow us to do things like serialize > > PREPAREd plans into a nicely compact single allocation that we could > > just pfree in a single pfree call on DEALLOCATE. > > I'm not sure what benefit you're refering to. If you mean "it's more > compact than the current format" then sure; but the other points can > already be covered by either the current nodeToString format, or by > nodeCopy-ing the prepared plan into its own MemoryContext, which would > allow us to do essentially the same thing.
There's significantly less memory involved in just having a plan serialised into a single chunk of memory vs a plan stored in its own MemoryContext. With the serialised plan, you don't have any power of 2 rounding up wastage that aset.c does and don't need extra space for all the MemoryChunks that would exist for every single palloc'd chunk in the MemoryContext version. I think it would be nice if one day in the future if a PREPAREd plan could have multiple different plans cached. We could then select which one to use by looking at statistics for the given parameters and choose the plan that's most suitable for the given parameters. Of course, this is a whole entirely different project. I mention it just because being able to serialise a plan would make the memory management and overhead for such a feature much more manageable. There'd likely need to be some eviction logic in such a feature as the number of possible plans for some complex query is quite likely to be much more than we'd care to cache. David