Обсуждение: 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) #