Stephan Szabo wrote:
> Wierd, I've not seen that behavior really, although I've never
> done time sensitive stuff. It might be the time before the
> shared cache updates? Not sure really. If you do the rule
> inline with your inserts (rather than a second transaction)
> does it still wait?
Just jumping in not having followed the discussion. But...
The rules applied to a table by the rewriter are taken out of
the relation descriptor that is returned by heap_open() or
heap_openr().
I haven't looked at the code, but pg_class only has a boolean
telling if a class has rules or not. Could it be that adding
more rules (or dropping just a few instead of all) doesn't
update the pg_class tuple, thus the syscache for the table
isn't invalidated and other backends continue to use the old
information instead of rescanning pg_rewrite?
Jan
>
> Stephan Szabo
> [EMAIL PROTECTED]
>
> On Tue, 22 Aug 2000, Joerg Hessdoerfer wrote:
>
> > Hi!
> >
> > At 08:18 18.08.00 -0700, you wrote:
> > [...]
> >
> > >I didn't try with vacuum, I just did a table lock and that
> > >seemed to still hang the inserts with two tables, so I figured
> > >maximum safety was adding the third table. If it works with two
> > >that's much cooler. Was this with real data or just a small test
> > >set?
> >
> > It was a test set ... ~20000 records, *BUT* I found that postgres
> > decides when it starts to use the rule - means, if you do continous
> > inserts on the table and create the rule, there's a varying time until
> > the rule applies. In my first tests, I re-connected the DB very often,
> > and the the change seemed immediate.
> >
> > Any ideas on how to 'promote' the rules faster?!?
> >
>
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
