Re: [PERFORM] Slow count(*) again...

2010-10-12 Thread Joe Uhl
The biggest single problem with "select count(*)" is that it is seriously overused. People use that idiom to establish existence, which usually leads to a performance disaster in the application using it, unless the table has no more than few hundred records. SQL language, of which PostgreSQL offe

Re: [PERFORM] Performance with sorting and LIMIT on partitioned table

2009-10-20 Thread Joe Uhl
On Mon, Oct 19, 2009 at 6:58 AM, Joe Uhl wrote: I have a similar, recent thread titled Partitioned Tables and ORDER BY with a decent break down. I think I am hitting the same issue Michal is. Essentially doing a SELECT against the parent with appropriate constraint columns in the WHERE clause

Re: [PERFORM] Performance with sorting and LIMIT on partitioned table

2009-10-19 Thread Joe Uhl
On Mon, Oct 12, 2009 at 10:14 AM, Michal Szymanski wrote: We have performance problem with query on partitioned table when query use order by and we want to use first/last rows from result set. More detail description: We have big table where each row is one telephone call (CDR). Definitni

Re: [PERFORM] Partitioned Tables and ORDER BY

2009-10-18 Thread Joe Uhl
This seems like a pretty major weakness in PostgreSQL partitioning. I have essentially settled on not being able to do queries against the parent table when I want to order the results. Going to have to use a Hibernate interceptor or something similar to rewrite the statements so they hit spe

[PERFORM] Partitioned Tables and ORDER BY

2009-10-08 Thread Joe Uhl
We have been using partitioning for some time with great success. Up until now our usage has not included ordering and now that we are trying to use an ORDER BY against an indexed column a rather significant shortcoming seems to be kicking in. Parent table (have cut all but 4 columns to make

Re: [PERFORM] Best suiting OS

2009-10-02 Thread Joe Uhl
rst). I've run dozens of distributions and this works well for us (a startup with nontrivial Linux experience). I imagine at a larger company it definitely would not be an option. Joe Uhl -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to you

Re: [PERFORM] High CPU Utilization

2009-03-24 Thread Joe Uhl
On Mar 20, 2009, at 4:58 PM, Scott Marlowe wrote: On Fri, Mar 20, 2009 at 2:49 PM, Joe Uhl wrote: On Mar 20, 2009, at 4:29 PM, Scott Marlowe wrote: What does the cs entry on vmstat say at this time? If you're cs is skyrocketing then you're getting a context switch storm

Re: [PERFORM] High CPU Utilization

2009-03-20 Thread Joe Uhl
On Mar 20, 2009, at 4:58 PM, Scott Marlowe wrote: On Fri, Mar 20, 2009 at 2:49 PM, Joe Uhl wrote: On Mar 20, 2009, at 4:29 PM, Scott Marlowe wrote: What does the cs entry on vmstat say at this time? If you're cs is skyrocketing then you're getting a context switch storm

Re: [PERFORM] High CPU Utilization

2009-03-20 Thread Joe Uhl
On Mar 20, 2009, at 4:29 PM, Scott Marlowe wrote: On Fri, Mar 20, 2009 at 2:26 PM, Joe Uhl wrote: On Mar 17, 2009, at 12:19 AM, Greg Smith wrote: On Tue, 17 Mar 2009, Gregory Stark wrote: Hm, well the tests I ran for posix_fadvise were actually on a Perc5 -- though who knows if it was

Re: [PERFORM] High CPU Utilization

2009-03-20 Thread Joe Uhl
On Mar 17, 2009, at 12:19 AM, Greg Smith wrote: On Tue, 17 Mar 2009, Gregory Stark wrote: Hm, well the tests I ran for posix_fadvise were actually on a Perc5 -- though who knows if it was the same under the hood -- and I saw better performance than this. I saw about 4MB/s for a single drive

Re: [PERFORM] High CPU Utilization

2009-03-16 Thread Joe Uhl
ly, Aretec and Promise are good, Adaptec good, depending on model, and the ones that Dell ship w/their servers haven't had good reviews/reports. On 03/16/2009 01:10 PM, Joe Uhl wrote: Here is vmstat 1 30. We are under peak load right now so I can gather information from the real deal :)

Re: [PERFORM] High CPU Utilization

2009-03-16 Thread Joe Uhl
back to the list on first try. On Mar 16, 2009, at 3:52 PM, Alan Hodgson wrote: On Monday 16 March 2009, Joe Uhl wrote: Right now (not under peak load) this server is running at 68% CPU utilization and its SATA raid 10 is doing about 2MB/s writes and 11MB/ s reads. When I run dd I can hi

[PERFORM] High CPU Utilization

2009-03-16 Thread Joe Uhl
greatly appreciated. Joe Uhl -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] hardware and For PostgreSQL

2007-11-01 Thread Joe Uhl
Magnus Hagander wrote: > Ron St-Pierre wrote: > >> Joe Uhl wrote: >> >>> I realize there are people who discourage looking at Dell, but i've been >>> very happy with a larger ball of equipment we ordered recently from >>> them. Our databas

Re: [PERFORM] hardware and For PostgreSQL

2007-10-31 Thread Joe Uhl
I realize there are people who discourage looking at Dell, but i've been very happy with a larger ball of equipment we ordered recently from them. Our database servers consist of a PowerEdge 2950 connected to a PowerVault MD1000 with a 1 meter SAS cable. The 2950 tops out at dual quad core cpus,

Re: [PERFORM] SAN vs Internal Disks

2007-09-06 Thread Joe Uhl
total in the past 2 years. Just my personal experience, i'd be happy to pass along the account manager's information if anyone is interested. > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate

Re: [PERFORM] Dell Hardware Recommendations

2007-08-09 Thread Joe Uhl
e from someone but I knew this list would provide some excellent ideas and feedback to get us started. Joe Uhl [EMAIL PROTECTED] On Thu, 9 Aug 2007 16:02:49 -0500, "Scott Marlowe" <[EMAIL PROTECTED]> said: > On 8/9/07, Joe Uhl <[EMAIL PROTECTED]> wrote: > > We have

[PERFORM] Dell Hardware Recommendations

2007-08-09 Thread Joe Uhl
configured, but want to get some hardware ballparks in order to get quotes and potentially request a trial unit. Any thoughts or recommendations? We are running openSUSE 10.2 with kernel 2.6.18.2-34. Regards, Joe Uhl [EMAIL PROTECTED] ---(end of broadcast

Re: [PERFORM] Opinions on Raid

2007-03-05 Thread Joe Uhl
Sent: Tuesday, February 27, 2007 12:56 PM To: Joe Uhl Cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] Opinions on Raid On Tue, 2007-02-27 at 07:12, Joe Uhl wrote: > We have been running Postgres on a 2U server with 2 disks configured in > raid 1 for the os and logs and 4 disks configu

[PERFORM] Opinions on Raid

2007-02-27 Thread Joe Uhl
We have been running Postgres on a 2U server with 2 disks configured in raid 1 for the os and logs and 4 disks configured in raid 10 for the data. I have since been told raid 5 would have been a better option given our usage of Dell equipment and the way they handle raid 10. I have just a few gen