Re: [HACKERS] [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL
Hi, Tom Lane schrieb: Robert Lor [EMAIL PROTECTED] writes: I ran pgbench and fired up a DTrace script using the lwlock probes we've added, and it looks like BufMappingLock is the most contended lock, but CheckpointStartLocks are held for longer duration! Those numbers look a bit suspicious --- I'd expect to see some of the LWLocks being taken in both shared and exclusive modes, but you don't show any such cases. You sure your script is counting correctly? Also, it'd be interesting to count time spent holding shared lock separately from time spent holding exclusive. Is there a test case which shows the contention for this full cached tables? It would be nice to have measurable numbers like context switches and queries per second. Sven. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] patch postgresql for AMD64 (Opteron)
Hi Tom, I remember that you provide a small SQL script to force the context switch storm. Can you provide a similar script for Pg 8.1.4? It looks to me that you get context switch storm if you access with SELECT one table from multiple clients. I have a customer which has an current XEON MP DualCore and we get 15+ context switches/sec. We have around 30 clients. We use RHEL 4 in 32-bit (i368) mode. I didn't use the patch for the Opteron-specific behavior. Cheers Sven. Tom Lane schrieb: Sven Geisler [EMAIL PROTECTED] writes: I created a patch for PostgreSQL and x86 architecture. This patch address a Opteron-specific behavior regarding some assembler statements. AFAICT this patch essentially proposes that we should allow the single case of an Opteron running in 32-bit mode to determine our optimization strategy for all 32-bit Intel. Tail wagging dog, no? As the comment notes, it's not real clear that the separate cmpb is a win on average, but this case is not the average case I'm interested in. If you want to make an argument for removing the cmpb you need to provide numbers on mainstream 32-bit platforms. regards, tom lane -- /This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you should not copy it, re-transmit it, use it or disclose its contents, but should return it to the sender immediately and delete your copy from your system. Thank you for your cooperation./ Sven Geisler [EMAIL PROTECTED] Tel +49.30.5362.1627 Fax .1638 Senior Developer,AEC/communications GmbHBerlin, Germany ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] patch postgresql for AMD64 (Opteron)
Hi all, I created a patch for PostgreSQL and x86 architecture. This patch address a Opteron-specific behavior regarding some assembler statements. The patch based on a patch to PostgreSQL 8.0.3 which was worked out by RedHat. Tom did change src/include/storage/s_lock.h for PostgreSQL 8.1.x. This change is only for x86_64. I need to compile PostgreSQL 8.1.4 for 32-bit on a Opteron. The reason for the 32-bit binary is a failover/test box with XEONs which didn't know anything about EM64T. Anyhow, I change the i386 part of s_lock.h too. BTW: Tom did a great job on BufMgrLock. The original patch for pg 8.0 did push the performance with many parallel queries on another level. We did run internal benchmarks and the patch version was 2.5 times faster. The benefit of this change to Pg 8.1.4 is much smaller. I did a test with pg_bench and the benefit is at around 10 percent. This change was tested on Opteron, XEON MP w/o EM64T and XEON DP without any issues. Cheers Sven. diff -Naur postgresql-8.1.4.orig/src/include/storage/s_lock.h postgresql-8.1.4/src/include/storage/s_lock.h --- postgresql-8.1.4.orig/src/include/storage/s_lock.h 2005-10-11 22:41:32.0 +0200 +++ postgresql-8.1.4/src/include/storage/s_lock.h 2006-05-31 09:19:04.0 +0200 @@ -125,12 +125,9 @@ * extra test appears to be a small loss on some x86 platforms and a small * win on others; it's by no means clear that we should keep it. */ + /* xchg implies a LOCK prefix, so no need to say LOCK explicitly */ __asm__ __volatile__( - cmpb$0,%1 \n - jne 1f \n - lock\n xchgb %0,%1 \n - 1: \n : +q(_res), +m(*lock) : : memory, cc); @@ -189,8 +186,8 @@ * is a huge loss. On EM64T, it appears to be a wash or small loss, * so we needn't bother to try to distinguish the sub-architectures. */ + /* xchg implies a LOCK prefix, so no need to say LOCK explicitly */ __asm__ __volatile__( - lock\n xchgb %0,%1 \n : +q(_res), +m(*lock) : ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PERFORM] [HACKERS] qsort again
Martijn van Oosterhout schrieb: Last time around there were a number of different algorithms tested. Did anyone run those tests while getting it to count the number of actual comparisons (which could easily swamp the time taken to do the actual sort in some cases)? The last time I did such tests is almost 10 years ago. I had used MetroWerks CodeWarrior C/C++, which had Quicksort as algorithm in the Lib C. Anyhow, I tested a few algorithms including merge sort and heapsort. I end up with heapsort because it was the fastest algorithm for our issue. We joined two arrays where each array was sorted and run qsort to sort the new array. Sven. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
