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 in

[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] 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 bv_bookge

[PERFORM] Effective Cache Size

2003-09-17 Thread Nick Barr
hared_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 a

[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 >

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

2003-10-10 Thread Nick Barr
Josh Berkus wrote: Nick, Having been following the thread on "go for a script! / ex: PostgreSQL vs. MySQL". I thought I would throw something together in Perl. Cool! Would you be willing to work with me so that I can inject some of my knowledge of .conf tuning? Sounds good to me.

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

2003-10-11 Thread Nick Barr
Josh Berkus wrote: shared_buffers = 1/16th of total memory effective_cache_size = 80% of the supposed kernel cache. But only if it's a dedicated DB machine. If it's not, all memory values should be cut in half. What I would prefer would be an interactive script which would, by asking th

[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=112&familyId =2 Looks like a four-channel hot-swap IDE (SATA) hardware RAID controller

[PERFORM] pg_autoconfig.pl

2003-11-22 Thread Nick Barr
Heya, Sorry for no updates on the old pg_autoconfig script thing, been rather busy at work the last week or two :-( but i suppose it pays the bills. I do have a few days off work now so I can spend some time on finishing the first version off. The latest version can be found at http://www.chuc

Re: [PERFORM] pg_autoconfig.pl

2003-11-24 Thread Nick Barr
- Original Message - From: "Josh Berkus" <[EMAIL PROTECTED]> To: "Nick Barr" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, November 22, 2003 5:19 PM Subject: Re: pg_autoconfig.pl > Nick, > > > Josh have you managed to put to

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

2004-01-14 Thread Nick Barr
pache processes. This pool can be limited to say 50 or 100 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

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] Linux / Clariion

2004-01-28 Thread Nick Barr
ariion, EMC is apparently 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)-

Re: [PERFORM] select max(id) from aTable is very slow

2004-02-16 Thread Nick Barr
David Teran wrote: Hi, we have a table with about 6.000.000 rows. There is an index on a column with the name id which is an integer and serves as primary key. When we execute select max(id) from theTable; it takes about 10 seconds. Explain analyze returns: -

Re: [PERFORM] select max(id) from aTable is very slow

2004-02-16 Thread Nick Barr
Nick Barr wrote: David Teran wrote: Hi, we have a table with about 6.000.000 rows. There is an index on a column with the name id which is an integer and serves as primary key. When we execute select max(id) from theTable; it takes about 10 seconds. Explain analyze returns

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] Slow join using network address function

2004-02-24 Thread Nick Barr
Tom Lane wrote: "Eric Jain" <[EMAIL PROTECTED]> writes: 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