Re: Rule recompilation

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rule recompilation
Date: 2001-07-12 19:25:20
Message-ID: 200107121925.f6CJPKA05260@jupiter.us.greatbridge.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Jan Wieck <JanWieck(at)yahoo(dot)com> writes:
> > This isn't local recompilation in current backend. It's
> > recreation of the pg_rewrite entry for a relation, including
> > propagation.
>
> Where I'd like to go (see my previous mail) is that pg_rewrite,
> pg_attrdef, and friends store *only* the source text of rules,
> default expressions, etc. No compiled trees at all in the database.
> So there's no need to update the database entries, but there is a
> need for something like a shared-cache-invalidation procedure to cause
> backends to recompile things that depend on updated relations.

Hmmm,

are you sure that this doesn't have a severe performance
impact?

When and how often are these parsetrees read? IIRC these
parsetree strings are interpreted somehow during heap_open().
Now you want to run a flex/bison plus tons of syscache
lookups for operator and function candidates and possible
casting in this place?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jean-Michel POURE 2001-07-12 19:26:49 Dependency tracking
Previous Message Jan Wieck 2001-07-12 19:18:15 Re: Rule recompilation