Herouth Maoz <herouth@oumail.openu.ac.il> writes:
> At 23:45 +0300 on 23/07/1999, John M. Flinchbaugh wrote:
>> [ how to avoid "rule plan string too big" ? ]
> First, I do believe that in the FROM clause, you don't use "as" to create
> table aliases. This is done only in the target list.
"AS" is an allowed noise word in FROM, see the production for table_expr
in gram.y. However, this sort of hacking on the text source of the
query isn't going to make much if any difference to the length of the
resulting parse tree, which is what John's actually running into trouble
with. The real problem is that a parse tree for a ten-way join with
this many output columns just plain has a lot of nodes :-(, and the way
that they're being stored in rules is quite verbose. (I think Jan is
going to introduce compression of rule plan strings shortly, but that's
not going to help John right now.)
He might have some luck by splitting the query into two subqueries,
one that joins half the tables and the other one joining the other half,
then a top query that joins those two. (The trick here is figuring
out how to split the tables into two groups that can be joined without
reference to the other group and without producing too many useless
tuples.) The top query is still going to be tight, because the number
of targetlist nodes (output columns) won't change, but reducing the
number of tables it references to two views and simplifying its WHERE
condition down to one or so clauses will both help eliminate nodes.
I originally thought that this wouldn't work because the final parsetree
for the top query would incorporate the other two parsetrees and still
be too big. But it looks like it doesn't --- when I experimented just
now, the stored parsetree for a view referencing another view treated
the sub-view as just a table with no inner structure. I suppose the
expansion doesn't happen until plan/optimize time.
regards, tom lane
