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
>
>
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 |