Re: BUG #16302: too many range table entries - when count partition table(65538 childs)

On Tue, Mar 17, 2020 at 9:49 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

That sounds like a lot of work, but I think AttrNumber is used to
store varattno, and I think varno is typically stored using either
Index or int, both of which are 32 bits. Am I confused?

(It doesn't seem like we're all that careful about whether we're using
int, which is signed, or Index, which is unsigned, and we might want
to go around and tighten that up. But if we adopted my suggested value
of a billion it still wouldn't make any difference, because 10^9<2^31.
I feel fairly safe saying that queries involving more than a billion
relations will be impractical for other reasons for many years yet.)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company