Re: Let's make PostgreSQL multi-threaded

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
Subject: Re: Let's make PostgreSQL multi-threaded
Date: 2023-06-05 19:03:37
Message-ID: CAFj8pRALmSZ-qHJ2+f5z7ckH_+=CpkEAZYp0b_bUXfYMjhz0ig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

In the long run, a single-process architecture makes it easier to have
> shared catalog caches, plan cache, etc. which can improve performance.
> And it can make it easier to launch helper threads for things where
> worker processes would be too heavy-weight. But those benefits will
> require more work, they won't happen just by replacing processes with
> threads.
>

The shared plan cache is not a silver bullet. The good management of shared
plan cache is very very difficult. Our heuristic about custom plans in
prepared statements is nothing, and you should reduce the usage of custom
plans too.

There are a lot of issues known from Oracle. The benefits can be just for
very primitive very fast queries, or extra complex queries where generic
plan is used. Current implementation of local plan caches has lot of
issues (that cannot be fixed), but shared plan cache is another level of
complexity

Regards

Pavel

>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2023-06-05 19:04:29 Re: Cleaning up nbtree after logical decoding on standby work
Previous Message Andrew Dunstan 2023-06-05 18:51:50 Re: Let's make PostgreSQL multi-threaded