Re: [HACKERS] [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL

2006-06-17 Thread Josh Berkus
Tom, 18% in s_lock is definitely bad :-(.  Were you able to determine which LWLock(s) are accounting for the contention? Gavin Sherry and Tom Daly (Sun) are currently working on identifying the problem lock using DLWLOCK_STATS. Any luck, Gavin? -- Josh Berkus PostgreSQL @ Sun San Francisco

Re: [PERFORM] Precomputed constants?

2006-06-17 Thread Jim Nasby
On Jun 15, 2006, at 1:19 PM, Zoltan Boszormenyi wrote: # select distinct provolatile from pg_proc; provolatile - i s v (3 sor) If I get this right, IMMUTABLE/STABLE/VOLATILE are indicated with their initials. That's probably correct. If the docs don't specify this then the code

Re: [PERFORM] Optimizer internals

2006-06-17 Thread Jim Nasby
On Jun 16, 2006, at 8:43 AM, Jonah H. Harris wrote: Yes, this is certainly the most noticible case. This is one reason I'm behind the freespace patch. Unfortunately, a lot of inexperienced people use VACUUM FULL and don't understand why VACUUM is *generally* better.(to free up block-level

Re: [PERFORM] SAN performance mystery

2006-06-17 Thread Jim Nasby
On Jun 16, 2006, at 6:28 AM, Greg Stark wrote: I never understood why disk caches on the order of megabytes are exciting. Why should disk manufacturers be any better about cache management than OS authors? In the case of RAID 5 this could actually work against you since the RAID controller

Re: [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL community

2006-06-17 Thread Jim Nasby
On Jun 16, 2006, at 12:01 PM, Josh Berkus wrote: Folks, I am thrill to inform you all that Sun has just donated a fully loaded T2000 system to the PostgreSQL community, and it's being setup by Corey Shields at OSL (osuosl.org) and should be online probably early next week. The system has