From: | Theo Schlossnagle <jesus(at)omniti(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Theo Schlossnagle <jesus(at)omniti(dot)com> |
Subject: | Interesting tight loop |
Date: | 2006-09-14 03:34:06 |
Message-ID: | DE8317DF-A8F3-456F-8BAA-C9911BFFF452@omniti.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
In production today (8.1.4), I ran into a backend process that
wouldn't cancel right away -- minutes went by.
It was in
[0] TransactionIdIsCurrentTransactionId
[1] HeapTupleSatisfiesSnapshot
...
But the interesting thing is that there were 4.6 million elements in
the s->childXids list. Which is why it took so damn long. I can't
quite figure out how I induced this state. It is an OLAP server with
about 10-20 connection that run "long" queries (from 5 seconds to 24
hours).
If this is a common possible state, it seems that perhaps a hash of
the childXids would be more appropriate. Does the order of the
childXids chained off the current transaction state matter? Most of
the placed I could find that reference it seem to just attempt to
find an Xid in there. O(1) sounds a lot better than O(n) :-D
Best regards,
Theo
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Say42 | 2006-09-14 04:47:14 | Re: Optimizer improvements: to do or not to do? |
Previous Message | Mark Dilger | 2006-09-14 02:22:45 | Re: Fixed length data types issue |