Re: [SQL] ERROR: DefineQueryRewrite: rule plan string too big.

From: wieck(at)debis(dot)com (Jan Wieck)
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: herouth(at)oumail(dot)openu(dot)ac(dot)il, glynis(at)butterfly(dot)hjsoft(dot)com, pgsql-sql(at)postgreSQL(dot)org
Subject: Re: [SQL] ERROR: DefineQueryRewrite: rule plan string too big.
Date: 1999-07-26 09:28:44
Message-ID: m118h3s-0003kvC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Tom Lane wrote:

> 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.

It happens during rewrite time. The querytree stored for
rules is just the UNrewritten output of the parser. That's
why the rewriter is recursively calling itself with it's own
output.

So splitting up such a huge view into a tree of views (if
possible) is a solution that must not result in a different
final querytree (after applying all view rules). It just
takes a little more time for the rewrite step - but I cannot
estimate how much more.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Herouth Maoz 1999-07-26 10:27:58 Re: [SQL] Expr Abbreviations/Functions?
Previous Message Christian Rudow 1999-07-26 09:09:07 NOT IN clause performing badly