Re: [HACKERS] Rule plan size for views?

> > > > Sounds like the plan internally grew (possible w/subselect stuff?!?) and
> > > > has gone over that 8k limit.
> > >
> > > I think it must be due to the cleanups in the node-print and
> > > read funcs. They now output/read ALL fields in the nodes.
> >
> > Oh, I didn't realize that the print functions were actually used for something
> > other than printing and debugging. I had started to add a few new nodes when I
> > was trying to debug the "primary key" code.
> >
> > Should we go through and bracket some of those with #ifdef QUERYDEBUG or
> > something like that? Where are they actually used? Should we try to keep these
> > at a minimum for production compiles of the system??
>
> Did you add stuff to dump that wasn't dumped before, or were they fields
> of existing structure that used to be skipped?
>
> They are used for the rewrite system and for views.

I added a few nodes (maybe two?), _and_ added some call-outs to existing nodes to
follow their children down. This stuff can be bracketed with debugging #ifdef's; it
was very helpful for me when debugging but it isn't good if they are adding
unnecessary limitations on sizes. The additional nodes I added are a "don't care";
it's the additional printing of child nodes (fields of existing structures) which
is loading things down.

I am not absolutely certain that we are talking about the same thing, so should
confirm that it is the same routines which are causing trouble; this is the same
printing/formatting code used for "explain"??

I'd be happy to help clean them up, but I think you should help too; as I recall we
were both mucking around there about the same time ;)

- Tom