"mal.oracledba" <mal.oracledba@xxxxxxxxx> writes: > A snapshot of 'perf' output for one of the users below. It doesnt change > much from that profile. You might want to look into whether you could use int or bigint instead of numeric for your indexed columns. That trace is showing 4.5% of runtime directly blamable on cmp_numerics plus its subroutine cmp_abs_common, and I'll bet that a noticeable fraction of the AllocSetAlloc, memcpy, and malloc traffic is attributable to numeric operations too. You could probably not expect to get much more than 5% savings, but still, if you don't need fractions then that's 5% that's just being wasted. The bigger picture here though is a lot of context swaps, and I wonder how much of that is blamable on your having activated commit_delay (especially with such silly settings as you chose ... more is not better there). The fact that XLogInsert shows up high on the profile might indicate that contention for WALInsertLock is a factor, though it's hardly proof of that. If that's the main problem there's not too much that can be done about it in the near term. (There's some work going on to reduce contention for that lock, but it's not done yet, let alone in 9.2.) In a real application you could possibly reduce the problem by rearranging operations, but that would be cheating of course for a benchmark. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
