From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, digoal(at)126(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #16302: too many range table entries - when count partition table(65538 childs) |
Date: | 2020-03-17 13:48:59 |
Message-ID: | 31331.1584452939@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Mar 15, 2020 at 10:38 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Well, if we say "PG can handle up to 64K relations in a query",
>> I think people would read that as meaning that you actually get
>> usable performance with up to 64K relations. Which is a long
>> way away, even if certain specific cases might work acceptably.
>> The existing docs discourage using more than a few thousand
>> partitions, IIRC, and that seems like sufficient guidance for now.
> Would would be the downside to raising INNER_VAR to, say, a billion?
We'd have to widen AttrNumber to int32 and find all the places that
assume it's only 16 bits. (Good luck with testing your way to having
any confidence in having found them all, so I'm not sure exactly how
to acquire such confidence.) Maybe someday that will be a profitable
use of developer effort, but I have to say that I think that day is
a long way off.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2020-03-17 14:33:11 | Re: BUG #16302: too many range table entries - when count partition table(65538 childs) |
Previous Message | Robert Haas | 2020-03-17 11:42:41 | Re: BUG #16302: too many range table entries - when count partition table(65538 childs) |