gjerde@icebox.org writes:
> gprof says:
> % cumulative self self total
> time seconds seconds calls us/call us/call name
> 100.00 0.01 0.01 3 3333.33 3333.33 ValidatePgVersion
I concur with the conclusion that this entry is bogus --- you haven't
got a fully functional installation of gprof, evidently :-(. Assuming
that the call counts are accurate, it's clear that memory allocation
and expression evaluation are the main time sinks. It surprises me
that there's so much allocation going on. (Could there be alloc/free
calls inside the regex matcher?)
How big did you say these tables were? The explain outputs you posted
before made them look pretty small ... but if you have not vacuumed the
tables lately, the optimizer might have a bad idea of how big they are.
The number of iterations through the tuple-level routines suggests that
several million tuple combinations are being processed.
> On the other hand, I did have a backend close on me earlier today. I
> didn't notice the core file until now however. The query(I think) that
> made this was a very simple SELECT. However, I was doing some other
> queries at about the same time(the query with problems above)
> Here's what gdb had to say:
> (gdb) bt
> #0 0x40101111 in __kill ()
> #1 0x40100d66 in raise (sig=6) at ../sysdeps/posix/raise.c:27
> #2 0x40102447 in abort () at ../sysdeps/generic/abort.c:88
> #3 0x80d734d in s_lock_stuck ()
> #4 0x80d73c1 in s_lock ()
Several other people have reported s_lock_stuck() aborts recently;
I don't think we quite know the cause yet...
regards, tom lane