Thread: Re: [HACKERS] Rules: first fix on monday
Tom, Jan, These were my thought too. 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. Keith. Thomas G. Lockhart <lockhart@alumni.caltech.edu> > > > > Whilst you are working on the rules system it would be nice if > > > you could look for an oportunity to store the plain text rule > > > definition at creation time. > > > If the definition were stored in a table column it would allow us > > > to dump and restore databases in a more complete way. > > Yes, that would really be nice and I had something the like > > already in mind. > > I'm not really sure if it's a good thing to save the rules > > definition text instead of the parsetree. The advantages of > > doing so would be that the rule could easily be dumped and > > (more important) that the rules can have more complicated > > actions (remember that the currently stored parsetrees can > > quickly override the size limit of a text type). > > > > Storing the definition text only would require to parse at > > least the actions any time, a rule should be fired on a > > query. Bad for performance - but must check if significant > > bad. > > How about storing both an internal form and the plain text source? That > way you can use the fast form internally and dump the plain text... > > - Tom
> 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
[Charset iso-8859-1 unsupported, filtering to ASCII...] > > 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. Obviously the real fix is for larger block sizes. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> > 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. -
>
> > 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.
> >
> > [...]
>
> Adding a column will take away from the already-tight space needed
> to keep the plan.
>
> [...]
>
> darrenk
The limited space for the querytrees and event qualification
is really a problem, that we should fix. And since we now
really support multiple action rewrite rules, it will become
more important.
I had something different in mind to make the space
unlimited. I could add an Oid field to pg_rewrite, pointing
to an extension record.
If a rule does not fit into one tuple, it is splitted into
multiple ones in rewriteDefine.c. All the extension tuples
have the event realtion set to the invalid Oid value to not
get fired everywhere.
I don't think that reading some extension records is too much
overhead compared against the rewrite work and the actions,
those MONSTER-rules will result in.
Comments?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #