[Not sure this really is relevant for -performance at this point]
On Thu, 17 Apr 2003, Stephan Szabo wrote:
> On Fri, 18 Apr 2003, Tom Lane wrote:
>
> > Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> > > It appears (from some not terribly scientific experiments - see below)
> > > that it's likely to be related to managing the deferred trigger queue
> > > given that in my case at least running the constraints non-deferred was
> > > negligible in comparison.
> >
> > At one time the deferred-trigger queue had an O(N^2) behavioral problem
> > for large N = number of pending trigger events. But I thought we'd
> > fixed that. What's the test case exactly? Can you get a profile with
> > gprof?
>
> I'm going to tomorrow hopefully - but it looks to me that we fixed one, but
Argh. I'm getting that state where gprof returns all 0s for times. I'm
pretty sure this has come up before along with how to get it to work, but
I couldn't find it in the archives. Someday I'll learn how to use gprof. :(
In any case, the call list seemed reasonable. It's currently doing O(n^2)
calls to MemoryContextReset and deferredTriggerCheckState in InvokeEvents
I don't see anything else that's at that kind of number of calls (50
million calls for a backend that's only done 10000 inserts stands out a
bit). Going only from last statement seems to make it linear (I think my
attempt is checking 1 too many trigger values, need to change that
probably).