| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Amit Langote <amitlangote09(at)gmail(dot)com> | 
| Cc: | 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-16 02:38:30 | 
| Message-ID: | 28094.1584326310@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> On Sun, Mar 15, 2020 at 12:03 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
>>> ERROR:  54000: too many range table entries
>> This hardly seems like a bug.  We do not support an infinite number of
>> partitions --- and in the real world, performance would have tanked
>> long before you got to this many partitions.
> Would it make sense to document this hard upper bound on the number of
> relations that can be handled by a query?
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2020-03-16 06:02:25 | BUG #16303: A condtion whether an index-only scan is possible includes a wrong | 
| Previous Message | Amit Langote | 2020-03-16 02:27:55 | Re: BUG #16302: too many range table entries - when count partition table(65538 childs) |