Re: [PERFORM] Simply join in PostrgeSQL takes too long

2004-04-27 Thread Nick Barr
Vitaly Belman wrote: Hello pgsql-performance, I discussed the whole subject for some time in DevShed and didn't achieve much (as for results). I wonder if any of you guys can help out: http://forums.devshed.com/t136202/s.html So cutting and pasting: - SCHEMA - CREATE TABLE

Re: [PERFORM] slow seqscan

2004-04-21 Thread Nick Barr
Edoardo Ceccarelli wrote: My first post to this list :) Scenario: I have a database used only with search queries with only one table that holds about 450.000/500.000 records. The table is well indexed so that most of the queries are executed with index scan but since there is a big text field

[PERFORM] MySQL vs PG TPC-H benchmarks

2004-04-21 Thread Nick Barr
Hi, Has anyone had a look at: http://people.ac.upc.es/zgomez/ I realize that MySQL PG cannot really be compared (especially when you consider the issues that MySQL has with things like data integrity) but still surely PG would perform better than the stats show (i.e. #7 31.28 seconds versus

Re: [PERFORM] Slow join using network address function

2004-02-24 Thread Nick Barr
Tom Lane wrote: Eric Jain [EMAIL PROTECTED] writes: http://word-to-the-wise.com/ipr.tgz is a datatype that contains a range of IPv4 addresses, and which has the various operators to make it GIST indexable. Great, this looks very promising. No cast operators between ipr and

Re: [PERFORM] Postgresql on SAN

2004-02-19 Thread Nick Barr
Josh Berkus wrote: Anjan, Has anyone designed/implemented postgresql server on storage networks? Yes, Zapatec.com runs their stuff this way. Probably others as well. Are there any design considerations? I don't know. Probably. Are there any benchmarks for storage products

Re: [PERFORM] Linux / Clariion

2004-01-28 Thread Nick Barr
setting EOL for 2005 sometime, which we aint to pleased about. Never mind, hopefully we will have some more money by that time.. Any other info just say and I will see what I can dig up. Nick Barr ---(end of broadcast)--- TIP 7: don't forget

Re: [PERFORM] Persistent Connections

2004-01-25 Thread Nick Barr
Hi, [EMAIL PROTECTED] wrote: Hi I have a php script and i make a pg_pconnect If i want to make 4-10 pg_query in that script Have i to close the connection at end of the script? (i would say yes, is it right?) If you want to make multiple pg_query's in a page you can, and you can use the same

Re: [PERFORM] 100 simultaneous connections, critical limit?

2004-01-14 Thread Nick Barr
connections. Problems occur under peak load where all 500 concurrent connections are in use, but all that should happen is there is a bit of a delay. Hope that (almost) makes sense, Kind Regards, Nick Barr WebBased Ltd. Christopher Browne wrote: Clinging to sanity, [EMAIL PROTECTED] (Jón

[PERFORM] IDE Hardware RAID Controller

2003-11-14 Thread Nick Barr
Heya, FYI just spotted this and thought I would pass it on, for all those who are looking at new boxes. http://www.theinquirer.net/?article=12665 http://www.promise.com/product/product_detail_eng.asp?productId=112familyId =2 Looks like a four-channel hot-swap IDE (SATA) hardware RAID controller

[PERFORM] go for a script! / ex: PostgreSQL vs. MySQL

2003-10-10 Thread Nick Barr
Heya Guys n Gals, Having been following the thread on go for a script! / ex: PostgreSQL vs. MySQL. I thought I would throw something together in Perl. My current issue is that I only have access to a RH Linux box and so cannot make it cross-platform on my own :-(. Anyhow please find it attached.

Re: [PERFORM] go for a script! / ex: PostgreSQL vs. MySQL

2003-10-10 Thread Nick Barr
- Original Message - From: Nick Barr [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 10, 2003 1:35 PM Subject: go for a script! / ex: PostgreSQL vs. MySQL I will also post it on me website and as I develop it further new versions will appear there http

[PERFORM] Effective Cache Size

2003-09-17 Thread Nick Barr
shared_buffers = 16000 (128 Mb) max_fsm_relations = 5000 max_fsm_pages = 50 vacuum_mem = 65535 Kind Regards, Nick Barr This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system