> > We could add another column to "pg_rewrite" which contained the
> > source for the rule. This could be used by pg_dump to dump the
> > rule creation statement, or by the user to see what the rule
> > actually does.
> >
> > Perhaps someone who knows how to graft in new columns could do
> > that now before we finalise 6.4, even if we don't use it straight
> > away it would serve as a marker.
> >
> > I believe a dump/restore is required for 6.3 to 6.4 so we might as
> > well get the catalog change in sooner rather than later.
>
> Adding a column will take away from the already-tight space needed
> to keep the plan.
>
> Perhaps a better way is to have a new non-cached system table that
> would be joined to pg_rewrite to show the plain-text plan when needed.
>
> Rather than require the user to know this join, postgres could (or
> should) have some system views (ala Oracle) to hide the underlying
> table structures and prevent any user except the superuser from
> modifying a system table without using a postgres command.
>
> darrenk
I don't think we should save plans in persistant storage at all. We did this
at Sybase and it was a major headache. Suddenly you can't dump/restore across
architectures. Minor changes to the structure of a plan require wholesale
upgrades or boatloads of compatibility code. Much more shared update access to
catalogs. Somehow the plan read and write code got very complex and tended
to screw up the saved plans which was no fun at all to debug (since the crash
comes a lot later than the damage) All this to save a bit of parsing.
You can get pretty much the same benefits without most of the problems by just
caching the plans in memory and reusing them. If we had a sharable cache that
would be even better.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- If simplicity worked, the world would be overrun with insects. -
