Re: Continuous inserts...

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
rescanningpg_rewrite?
 


Jan

>
> Stephan Szabo
> sszabo@bigpanda.com
>
> 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.                                  #
#================================================== JanWieck@Yahoo.com #