[PERFORM] Why the difference in plans ??

2006-09-15 Thread Joost Kraaijeveld
Hi, I have two table: customers and salesorders. salesorders have a foreign key to the customer If I run this query: SELECT salesOrders.objectid, salesOrders.ordernumber, salesOrders.orderdate, customers.objectid, customers.customernumber, customers.lastname FROM prototype.salesorders

Re: [PERFORM] High CPU Load

2006-09-15 Thread Markus Schaber
Hi, Jérôme, Jérôme BENOIS wrote: max_connections = 512 Do you really have that much concurrent connections? Then you should think about getting a larger machine, probably. You will definitely want to play with commit_delay and commit_siblings settings in that case, especially if you have

Re: [PERFORM] Vacuums on large busy databases

2006-09-15 Thread Markus Schaber
Hi, Francisco, Francisco Reyes wrote: I am looking to either improve the time of the vacuum or decrease it's impact on the loads. Are the variables: #vacuum_cost_delay = 0 # 0-1000 milliseconds #vacuum_cost_page_hit = 1 # 0-1 credits

Re: [PERFORM] Why the difference in plans ??

2006-09-15 Thread Tom Lane
Joost Kraaijeveld [EMAIL PROTECTED] writes: Why the difference and can I influence the result so that the first query plan (which is the fastest) is actually used in both cases (I would expect that the limit would be done after the sort?)? It likes the second plan because 6694025.41/353

[PERFORM] Optimize SQL

2006-09-15 Thread Pallav Kalva
Hi, Is there anyway we can optimize this sql ? it is doing full table scan on listing and address table . Postgres version 8.0.2 Thanks! Pallav. explain analyze select listing0_.listingid as col_0_0_, getmaxdate(listing0_.lastupdate, max(addressval2_.createdate)) as col_1_0_ from

Re: [PERFORM] RAID 0 not as fast as expected

2006-09-15 Thread Luke Lonergan
Greg, Josh, Something I found out while doing this - lvm (and lvm2) slows the block stream down dramatically. At first I was using it for convenience sake to implement partitions on top of the md devices, but I found I was stuck at about 700 MB/s. Removing lvm2 from the picture allowed me to

Re: [PERFORM] Optimize SQL

2006-09-15 Thread Tom Lane
Pallav Kalva [EMAIL PROTECTED] writes: select listing0_.listingid as col_0_0_, getmaxdate(listing0_.lastupdate, max(addressval2_.createdate)) as col_1_0_ from listing.listing listing0_ left outer join listing.address listingadd1_ on listing0_.fkbestaddressid=listingadd1_.addressid left

Re: [PERFORM] Why the difference in plans ??

2006-09-15 Thread Joost Kraaijeveld
On Fri, 2006-09-15 at 10:08 -0400, Tom Lane wrote: but it seems there are only 7. Try increasing your statistics target and re-analyzing. Do you mean with increasing my statistics target changing the value of default_statistics_target = 10 to a bigger number? If so, changing it to 900 did not

Re: [PERFORM] Why the difference in plans ??

2006-09-15 Thread Tom Lane
Joost Kraaijeveld [EMAIL PROTECTED] writes: Do you mean with increasing my statistics target changing the value of default_statistics_target = 10 to a bigger number? If so, changing it to 900 did not make any difference (PostgreSQL restarted, vacuumed analysed etc). Hm, did the 353 rowcount

Re: [PERFORM] Optimize SQL

2006-09-15 Thread Arjen van der Meijden
On 15-9-2006 17:53 Tom Lane wrote: If that WHERE logic is actually what you need, then getting this query to run quickly seems pretty hopeless. The database must form the full outer join result: it cannot discard any listing0_ rows, even if they have lastupdate outside the given range, because

Re: [PERFORM] RAID 0 not as fast as expected

2006-09-15 Thread Bucky Jordan
When we first started working with Solaris ZFS, we were getting about 400-600 MB/s, and after working with the Solaris Engineering team we now get rates approaching 2GB/s. The updates needed to Solaris are part of the Solaris 10 U3 available in October (and already in Solaris Express, aka Solaris

[PERFORM] Performance of IN (...) vs. = ANY array[...]

2006-09-15 Thread Benjamin Minshall
Greetings: I'm running 8.1.4, and have noticed major differences in execution time for plpgsql functions running queries that differ only in use of an array such as: slower_function( vals integer[] ) [query] WHERE id = ANY vals; faster_function( vals integer[] ) vals_text

Re: [PERFORM] Performance of IN (...) vs. = ANY array[...]

2006-09-15 Thread Tom Lane
Benjamin Minshall [EMAIL PROTECTED] writes: What are the advantages or disadvantages of using arrays in this situation? The = ANY array method makes plpgsql development cleaner, but seems to really lack performance in certain cases. In existing releases, the form with IN

Re: [PERFORM] RAID 0 not as fast as expected

2006-09-15 Thread Luke Lonergan
Josh, On 9/14/06 8:47 PM, Joshua D. Drake [EMAIL PROTECTED] wrote: I've obtained 1,950 MB/s using Linux software RAID on SATA drives. With what? :) Sun X4500 (aka Thumper) running stock RedHat 4.3 (actually CentOS 4.3) with XFS and the linux md driver without lvm. Here is a summary of the