From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
Cc: | 'Konstantin Knizhnik' <k(dot)knizhnik(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Postgres is not able to handle more than 4k tables!? |
Date: | 2020-07-14 22:59:03 |
Message-ID: | 20200714225903.GC17494@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 10, 2020 at 02:10:20AM +0000, tsunakawa(dot)takay(at)fujitsu(dot)com
wrote:
> > There were many proposed patches which help to improve this
> > situation. But as far as this patches increase performance only
> > at huge servers with large number of cores and show almost no
> > improvement (or even some degradation) at standard 4-cores desktops,
> > almost none of them were committed. Consequently our customers have
> > a lot of troubles trying to replace Oracle with Postgres and provide
> > the same performance at same (quite good and expensive) hardware.
>
> Yeah, it's a pity that the shiny-looking patches from Postgres Pro
> (mostly from Konstantin san?) -- autoprepare, built-in connection
> pooling, fair lwlock, and revolutionary multi-threaded backend --
> haven't gained hot atension.
Yeah, it is probably time for us to get access to a current large-scale
machine again and really find the bottlenecks. We seem to next this
every few years.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-07-14 23:12:25 | Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind" |
Previous Message | Peter Geoghegan | 2020-07-14 22:49:40 | Re: Default setting for enable_hashagg_disk |