pgsql: Remove arbitrary 64K-or-so limit on rangetable size. - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Remove arbitrary 64K-or-so limit on rangetable size.
Date
Msg-id E1mQZNX-0005BZ-Og@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Remove arbitrary 64K-or-so limit on rangetable size.

Up to now the size of a query's rangetable has been limited by the
constants INNER_VAR et al, which mustn't be equal to any real
rangetable index.  65000 doubtless seemed like enough for anybody,
and it still is orders of magnitude larger than the number of joins
we can realistically handle.  However, we need a rangetable entry
for each child partition that is (or might be) processed by a query.
Queries with a few thousand partitions are getting more realistic,
so that the day when that limit becomes a problem is in sight,
even if it's not here yet.  Hence, let's raise the limit.

Rather than just increase the values of INNER_VAR et al, this patch
adopts the approach of making them small negative values, so that
rangetables could theoretically become as long as INT_MAX.

The bulk of the patch is concerned with changing Var.varno and some
related variables from "Index" (unsigned int) to plain "int".  This
is basically cosmetic, with little actual effect other than to help
debuggers print their values nicely.  As such, I've only bothered
with changing places that could actually see INNER_VAR et al, which
the parser and most of the planner don't.  We do have to be careful
in places that are performing less/greater comparisons on varnos,
but there are very few such places, other than the IS_SPECIAL_VARNO
macro itself.

A notable side effect of this patch is that while it used to be
possible to add INNER_VAR et al to a Bitmapset, that will now
draw an error.  I don't see any likelihood that it wouldn't be a
bug to include these fake varnos in a bitmapset of real varnos,
so I think this is all to the good.

Although this touches outfuncs/readfuncs, I don't think a catversion
bump is required, since stored rules would never contain Vars
with these fake varnos.

Andrey Lepikhov and Tom Lane, after a suggestion by Peter Eisentraut

Discussion: https://postgr.es/m/43c7f2f5-1e27-27aa-8c65-c91859d15190@postgrespro.ru

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/e3ec3c00d85bd2844ffddee83df2bd67c4f8297f

Modified Files
--------------
src/backend/executor/execScan.c           |  2 +-
src/backend/executor/execUtils.c          |  6 ++---
src/backend/executor/nodeCustom.c         |  2 +-
src/backend/executor/nodeForeignscan.c    |  2 +-
src/backend/nodes/makefuncs.c             |  8 +++----
src/backend/nodes/outfuncs.c              |  2 +-
src/backend/nodes/readfuncs.c             |  2 +-
src/backend/optimizer/path/costsize.c     |  3 ++-
src/backend/optimizer/plan/createplan.c   |  3 ++-
src/backend/optimizer/plan/setrefs.c      | 40 +++++++++++--------------------
src/backend/optimizer/prep/prepjointree.c |  4 ++--
src/backend/utils/adt/ruleutils.c         |  6 ++---
src/include/executor/executor.h           |  4 ++--
src/include/nodes/makefuncs.h             |  6 ++---
src/include/nodes/primnodes.h             | 15 ++++++------
15 files changed, 48 insertions(+), 57 deletions(-)


pgsql-committers by date:

Previous
From: Peter Eisentraut
Date:
Subject: pgsql: Add Cardinality typedef
Next
From: Andres Freund
Date:
Subject: pgsql: process startup: Initialize PgStartTime earlier in single user m