One more unexpected benefit of having shared caches would be easing
access to other databases.
If the system caches are there for all databases anyway, then it
becomes much easier to make queries using objects from multiple
databases.
Note that this does not strictly need threads, just shared caches.
On Thu, Jun 15, 2023 at 11:04 AM Hannu Krosing <hannuk@google.com> wrote:
>
> On Thu, Jun 15, 2023 at 10:41 AM James Addison <jay@jp-hosting.net> wrote:
> >
> > This is making me wonder about other performance/scalability areas
> > that might not have been considered due to focus on the details of the
> > existing codebase, but I'll save that for another thread and will try
> > to learn more first.
>
> A gradual move to more shared structures seems to be a way forward
>
> It should get us all the benefits of threading minus the need for TLB
> reloading and (in some cases) reduction of per-process virtual memory
> mapping tables.
>
> In any case we would need to implement all the locking and parallelism
> management of these shared structures that are not there in the
> current process architecture.
>
> So a fair bit of work but also a clearly defined benefits of
> 1) reduced memory usage
> 2) no need to rebuild caches for each new connection
> 3) no need to track PREPARE statements inside connection poolers.
>
> There can be extra complexity when different connections use the same
> prepared statement name (say "PREP001") for different queries.
> For this wel likely will need a good cooperation with connection
> pooler where it passes some kind of client connection id along at the
> transaction start