From: | Konstantin Knizhnik <knizhnik(at)garret(dot)ru> |
---|---|
To: | Hannu Krosing <hannuk(at)google(dot)com>, James Addison <jay(at)jp-hosting(dot)net> |
Cc: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Let's make PostgreSQL multi-threaded |
Date: | 2023-06-15 19:49:23 |
Message-ID: | 361f63ed-2a1a-7b1f-65a2-d7cadee76937@garret.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 15.06.2023 12:04 PM, Hannu Krosing wrote:
> 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.
Shared plan cache (not only prepared statements cache) also opens way to
more sophisticated query optimizations.
Right now we are not performing some optimization (like constant
expression folding) just because them increase time of processing normal
queries.
This is why queries generated by ORMs or wizards, which can contain a
lot of dumb stuff, are not well simplified by Postgres.
With MS-Sql it is quite frequent that query execution time is much
smaller than query optimization time.
Having shared plan cache allows us to spend more time in optimization
without risk to degrade performance.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-06-15 20:11:23 | Re: Memory leak in incremental sort re-scan |
Previous Message | Konstantin Knizhnik | 2023-06-15 19:36:30 | Re: Let's make PostgreSQL multi-threaded |