Re: [HACKERS] Rule plan size for views?

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Jan Wieck <jwieck(at)debis(dot)com>
Cc: maillist(at)candle(dot)pha(dot)pa(dot)us, darrenk(at)insightdist(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Rule plan size for views?
Date: 1998-03-03 02:50:07
Message-ID: 34FB6FDE.95211AE5@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck wrote:

> Hi,
>
> >
> > > > > > 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 ;)
>
> I think we talk about the same group of functions. But I'm
> not sure if the nodes you're talking about are parsenodes.
> Only parsenodes are printed during rule creation to build the
> querytree string stored in the pg_rewrite catalog (views are
> implemented by rules and do an internal CREATE RULE on CREATE
> VIEW).
>
> Anyway - If your nodes are parsenodes and you didn't created
> the corresponding node readfuncs, I would expect trouble
> during the rewrite handling when the printed rule action is
> parsed back to the backends internal querytree structures.

Well, how to we come to a conclusion here? Here are apparently new calls (since v6.2.1)
in outfuncs.c which could print out something. There are a few, and some may be printed
as children of parsetree nodes. Anyone have an idea if any of these are in parsetree
nodes and could be affecting the view and rewrite storage?

btw, I don't recall doing anything in the readfuncs, so there aren't likely any new
routines there.

- Tom

> _outCreateStmt(StringInfo str, CreateStmt *node)
> _outNode(str, node->tableElts);
> _outNode(str, node->inhRelnames);
> _outNode(str, node->constraints);
> _outIndexStmt(StringInfo str, IndexStmt *node)
> _outNode(str, node->indexParams);
> _outNode(str, node->withClause);
> _outNode(str, node->whereClause);
> _outNode(str, node->rangetable);
> _outColumnDef(StringInfo str, ColumnDef *node)
> _outNode(str, node->typename);
> _outNode(str, node->constraints);
> _outTypeName(StringInfo str, TypeName *node)
> _outNode(str, node->arrayBounds);
> _outIndexElem(StringInfo str, IndexElem *node)
> _outNode(str, node->args);
> _outNode(str, node->tname);
> case T_CreateStmt:
> _outNode(str, node->utilityStmt);
> case T_IndexStmt:
> _outNode(str, node->utilityStmt);
> case T_NotifyStmt:
> _outNode(str, node->sortClause);
> _outNode(str, node->groupClause);
> _outNode(str, node->havingQual);
> _outNode(str, node->unionClause);
> _outSortClause(StringInfo str, SortClause *node)
> _outNode(str, node->resdom);
> _outGroupClause(StringInfo str, GroupClause *node)
> _outNode(str, node->entry);
> sprintf(buf, " :size %d ", node->plan_size);
> sprintf(buf, " :width %d ", node->plan_width);
> _outIntList(str, node->extParam);
> _outIntList(str, node->locParam);
> _outNode(str, node->initPlan);
> _outNode(str, node->unionrts);
> _outSubPlan(StringInfo str, SubPlan *node)
> _outNode(str, node->plan);
> sprintf(buf, " :planid %u ", node->plan_id);
> _outNode(str, node->rtable);
> _outIntList(str, node->setParam);
> _outIntList(str, node->parParam);
> _outNode(str, node->sublink);
> _outNode(str, node->aggs);
> appendStringInfo(str, node->fj_initialized ? "true" : "false");
> sprintf(buf, " :nNodes %d ", node->fj_nNodes);
> appendStringInfo(str, (node->fj_alwaysDone[i]) ? "true" : "false");
> case SUBPLAN_EXPR:
> _outNode(str, node->target);
> _outSubLink(StringInfo str, SubLink *node)
> _outNode(str, node->lefthand);
> _outNode(str, node->oper);
> _outNode(str, node->subselect);
> _outNode(str, node->expr);
> _outAExpr(StringInfo str, A_Expr *node)
> _outNode(str, node->lexpr);
> _outNode(str, node->rexpr);
> _outIdent(StringInfo str, Ident *node)
> _outAConst(StringInfo str, A_Const *node)
> _outValue(str, &(node->val));
> case T_CreateStmt:
> _outCreateStmt(str, obj);
> case T_IndexStmt:
> _outIndexStmt(str, obj);
> case T_ColumnDef:
> _outColumnDef(str, obj);
> case T_TypeName:
> _outTypeName(str, obj);
> case T_IndexElem:
> _outIndexElem(str, obj);
> case T_SortClause:
> _outSortClause(str, obj);
> case T_GroupClause:
> _outGroupClause(str, obj);
> case T_SubPlan:
> _outSubPlan(str, obj);
> case T_SubLink:
> _outSubLink(str, obj);
> case T_A_Expr:
> _outAExpr(str, obj);
> case T_Ident:
> _outIdent(str, obj);
> case T_A_Const:
> _outAConst(str, obj);

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-03-03 03:00:28 PostgreSQL v6.3 is Released!! (fwd)
Previous Message Bruce Momjian 1998-03-03 02:29:17 Re: [HACKERS] Rule plan size for views?