From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Postgres is not able to handle more than 4k tables!? |
Date: | 2020-07-09 15:14:29 |
Message-ID: | 1819460.1594307669@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> So, that's really the core of your problem. We don't promise that
>> you can run several thousand backends at once. Usually it's recommended
>> that you stick a connection pooler in front of a server with (at most)
>> a few hundred backends.
> Sure, but that doesn't mean things should completely fall over when we
> do get up to larger numbers of backends, which is definitely pretty
> common in larger systems.
As I understood the report, it was not "things completely fall over",
it was "performance gets bad". But let's get real. Unless the OP
has a machine with thousands of CPUs, trying to run this way is
counterproductive.
Perhaps in a decade or two such machines will be common enough that
it'll make sense to try to tune Postgres to run well on them. Right
now I feel no hesitation about saying "if it hurts, don't do that".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2020-07-09 15:22:43 | Re: Is this a bug in pg_current_logfile() on Windows? |
Previous Message | Tom Lane | 2020-07-09 15:04:13 | Re: Is this a bug in pg_current_logfile() on Windows? |