Re: [PERFORM] Best suiting OS

2009-10-05 Thread Craig James
Scott Marlowe wrote: Personally, I use Fedora, and my servers have been quite stable. One of our main web servers running Fedora: It's not that there can't be stable releases of FC, it's that it's not the focus of that project. So, if you get lucky, great! I can't imagine running a

Re: [PERFORM] updating a row in a table with only one row

2009-10-05 Thread Michal Vitecek
Robert Haas wrote: On Fri, Oct 2, 2009 at 9:54 AM, Merlin Moncure mmonc...@gmail.com wrote: On Fri, Oct 2, 2009 at 4:18 AM, Michal Vitecek f...@mageo.cz wrote:  Hello everyone,  I'm using PostgreSQL 8.3.8 running on a server with 2 Xeon CPUs, 4GB  RAM, 4+2 disks in RAID 5 and CentOS 5.3.

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Devrim GÜNDÜZ
On Sun, 2009-10-04 at 15:51 -0400, Mark Mielke wrote: How do you provide effective support for a kernel that has 3000 back ported patches against it? This is again nonsense. Red Hat employs top kernel hackers. They do maintain vanilla kernel. It is not hard for Red Hat to maintain their own

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Jean-Michel Pouré
On Thu, 2009-10-01 at 15:16 +0530, S Arvind wrote: What is the best Linux flavor for server which runs postgres alone. The postgres must handle greater number of database around 200 +. Performance on speed is the vital factor. Is it FreeBSD, CentOS, Fedora, Redhat xxx?? Go for Debian:

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Devrim GÜNDÜZ
On Sun, 2009-10-04 at 15:51 -0400, Mark Mielke wrote: If somebody were to come to you with a *new* deployment request, what would you recommend? Would you really recommend RHEL 5 *today*? Well, I would, and I do recommend people. RHEL5 is well-tested, and stable. Many hardware vendors support

Re: [PERFORM] updating a row in a table with only one row

2009-10-05 Thread Merlin Moncure
On Mon, Oct 5, 2009 at 5:17 AM, Michal Vitecek f...@mageo.cz wrote:  Could the problem be the HW RAID card? There's ServerRAID 8k with 256MB  with write-back enabled. Could it be that its internal cache becomes  full and all disk I/O operations are delayed until it writes all  changes to hard

Re: [PERFORM] Bad performance of SELECT ... where id IN (...)

2009-10-05 Thread Robert Haas
On Sun, Oct 4, 2009 at 9:58 PM, Omar Kilani omar.kil...@gmail.com wrote: Hi Xia, Try this patch: http://treehou.se/~omar/postgresql-8.4.1-array_sel_hack.patch It's a hack, but it works for us. I think you're probably spending most of your query time planning, and this patch helps speed

Re: [PERFORM] Bad performance of SELECT ... where id IN (...)

2009-10-05 Thread Omar Kilani
Robert, On Mon, Oct 5, 2009 at 11:01 PM, Robert Haas robertmh...@gmail.com wrote: On Sun, Oct 4, 2009 at 9:58 PM, Omar Kilani omar.kil...@gmail.com wrote: Hi Xia, Try this patch: http://treehou.se/~omar/postgresql-8.4.1-array_sel_hack.patch It's a hack, but it works for us. I think you're

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Adam Tauno Williams
On Sun, 2009-10-04 at 10:05 -0400, Mark Mielke wrote: On 10/01/2009 03:44 PM, Denis Lussier wrote: I'm a BSD license fan, but, I don't know much about *BSD otherwise (except that many advocates say it runs PG very nicely). On the Linux side, unless your a dweeb, go with a newer, popular

Re: [PERFORM] Bad performance of SELECT ... where id IN (...)

2009-10-05 Thread Grzegorz Jaśkiewicz
On Mon, Oct 5, 2009 at 1:24 PM, Omar Kilani omar.kil...@gmail.com wrote: I'm not really sure what the alternatives are -- it never really makes sense to get the selectivity for thousands of items in the IN clause. I've never seen a different plan for the same query against a DB with that

Re: Maybe OT, not sure Re: [PERFORM] Best suiting OS

2009-10-05 Thread Adam Tauno Williams
Maybe - if the only thing the server is running is PostgreSQL. Show of hands - how many users who ONLY install PostgreSQL, and use a bare minimum OS install, choosing to not run any other software? Now, how many people ALSO run things like PHP, and require software more up-to-date than 3

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Robert Haas
On Mon, Oct 5, 2009 at 2:00 AM, Craig James craig_ja...@emolecules.com wrote: Fedora is a very nice project, but it's not suitable for production database servers. The trick is to write such a kick-ass application that before the Fedora support window ends, the load has increased enough that

Re: [PERFORM] Speed / Server

2009-10-05 Thread Nikolas Everett
But you should plan on partitioning to multiple db servers up front and save pain of conversion later on. A dual socket motherboard with 16 to 32 SAS drives and a fast RAID controller is WAY cheaper than a similar machine with 4 to 8 sockets is gonna be. And if you gotta go there anyway,

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Jean-David Beyer
Robert Haas wrote (in part): Also, I'd just like to mention that vi is a much better editor than emacs. That is not my impression. I have used vi from when it first came out (I used ed before that) until about 1998 when I first installed Linux on one of my machines and started using emacs. I

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Adam Tauno Williams
On Mon, 2009-10-05 at 09:37 -0400, Jean-David Beyer wrote: Robert Haas wrote (in part): Also, I'd just like to mention that vi is a much better editor than emacs. That is not my impression. I have used vi from when it first came out (I used ed before that) until about 1998 when I first

Re: [PERFORM][OT] Best suiting OS

2009-10-05 Thread Csaba Nagy
Hi Jean-David, On Mon, 2009-10-05 at 15:37 +0200, Jean-David Beyer wrote: Robert Haas wrote (in part): Also, I'd just like to mention that vi is a much better editor than emacs. That is not my impression. I have used vi from when it first came out (I used ed before that) until about

[PERFORM] Query plan for NOT IN

2009-10-05 Thread Matthew Wakeling
mnw21-modmine-r13features-copy=# select count(*) from project; count --- 10 (1 row) mnw21-modmine-r13features-copy=# select count(*) from intermineobject; count -- 26344616 (1 row) mnw21-modmine-r13features-copy=# \d intermineobject; Table public.intermineobject Column |

Re: [PERFORM] Query plan for NOT IN

2009-10-05 Thread Grzegorz Jaśkiewicz
On Mon, Oct 5, 2009 at 2:52 PM, Matthew Wakeling matt...@flymine.orgwrote: mnw21-modmine-r13features-copy=# select count(*) from project; count --- 10 (1 row) mnw21-modmine-r13features-copy=# select count(*) from intermineobject; count -- 26344616 (1 row)

Re: [PERFORM] Query plan for NOT IN

2009-10-05 Thread Grzegorz Jaśkiewicz
2009/10/5 Matthew Wakeling matt...@flymine.org Yes, that does work, but only because id is NOT NULL. I thought Postgres 8.4 had had a load of these join types unified to make it less important how the query is written? well, as a rule of thumb - unless you can't think of a default value of

Re: [PERFORM] Query plan for NOT IN

2009-10-05 Thread Tom Lane
Matthew Wakeling matt...@flymine.org writes: Yes, that does work, but only because id is NOT NULL. I thought Postgres 8.4 had had a load of these join types unified to make it less important how the query is written? NOT IN is not easily optimizable because of its odd behavior in the

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Stefan Kaltenbrunner
Stefan Kaltenbrunner wrote: Devrim GÜNDÜZ wrote: On Mon, 2009-10-05 at 12:07 +0200, Jean-Michel Pouré wrote: Go for Debian: * It is a free community, very active. Well, we need to state that this is not a unique feature. * It is guaranteed to be upgradable. Depends. I had lots of issues

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Karl Denninger
Scott Carey wrote: On 10/3/09 7:35 PM, Karl Denninger k...@denninger.net wrote: I am a particular fan of FreeBSD, and in some benchmarking I did between it and CentOS FreeBSD 7.x literally wiped the floor with the CentOS release I tried on IDENTICAL hardware. I also like the 3ware raid

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Claus Guttesen
However, I have certainly seen some inefficiencies with Linux and large use of shared memory -- and I wouldn't be surprised if these problems don't exist on FreeBSD or OpenSolaris. This came on the freebsd-performance-list a few days ago.

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Scott Carey
On 10/5/09 10:27 AM, Karl Denninger k...@denninger.net wrote: Scott Carey wrote: On 10/3/09 7:35 PM, Karl Denninger k...@denninger.net mailto:k...@denninger.net wrote: I am a particular fan of FreeBSD, and in some benchmarking I did between it and CentOS FreeBSD 7.x

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Karl Denninger
Claus Guttesen wrote: However, I have certainly seen some inefficiencies with Linux and large use of shared memory -- and I wouldn't be surprised if these problems don't exist on FreeBSD or OpenSolaris. This came on the freebsd-performance-list a few days ago.

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Karl Denninger
Axel Rau wrote: Am 05.10.2009 um 19:42 schrieb Karl Denninger: I have not yet benchmarked FreeBSD 8.x - my production systems are all on FreeBSD 7.x at present. The improvement going there from 6.x was MASSIVE. 8.x is on my plate to start playing with in the next couple of months. Did you

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Axel Rau
Am 05.10.2009 um 19:42 schrieb Karl Denninger: I have not yet benchmarked FreeBSD 8.x - my production systems are all on FreeBSD 7.x at present. The improvement going there from 6.x was MASSIVE. 8.x is on my plate to start playing with in the next couple of months. Did you ever try

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Karl Denninger
Scott Carey wrote: On 10/5/09 10:27 AM, Karl Denninger k...@denninger.net wrote: I don't run the 3x series 3ware boards. If I recall correctly they're not true coprocessor boards and rely on the host CPU. Those are always going to be a lose compared to a true coprocessor with dedicated

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Greg Smith
On Sun, 4 Oct 2009, Mark Mielke wrote: I can show you tickets where RedHat has specifically state they *will not* update the kernel to better support new hardware, for fear of breaking support for older hardware. There are two reasonable paths you'll find in the Open Source world, which

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Scott Carey
On 10/5/09 11:15 AM, Karl Denninger k...@denninger.net wrote: Scott Carey wrote: On 10/5/09 10:27 AM, Karl Denninger k...@denninger.net wrote: I don't run the 3x series 3ware boards. If I recall correctly they're not true coprocessor boards and rely on the host CPU. Those are always

Re: [PERFORM] Speed while runnning large transactions.

2009-10-05 Thread Greg Smith
On Fri, 2 Oct 2009, Tom Lane wrote: The people who hollered loudest about this seemed to often have long-running read-only transactions in parallel with lots of short read-write transactions. Which makes sense if you think about it. Long-running read-only reports are quite common in DBA

[PERFORM] Distributed/Parallel Computing

2009-10-05 Thread Viji V Nair
Hi Team, This question may have asked many times previously also, but I could not find a solution for this in any post. any help on the following will be greatly appreciated. We have a PG DB with PostGIS functions. There are around 100 tables in the DB and almost all the tables contains 1

Re: [PERFORM] Query plan for NOT IN

2009-10-05 Thread Guy Rouillier
Grzegorz Jaśkiewicz wrote: well, as a rule of thumb - unless you can't think of a default value of column - don't use nulls. So using nulls as default 'idunno' - is a bad practice, but everybody's opinion on that differ. I don't understand this point of view. The concept of null was

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Karl Denninger
Scott Carey wrote: On 10/5/09 11:15 AM, Karl Denninger k...@denninger.net wrote: I'm running the 9650s in most of my busier machines. Haven't tried a PERC card yet - its on my list. Most of my stuff is configured as RAID 1 although I have a couple of RAID 10 arrays in service; depending

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Kevin Grittner
Claus Guttesen kome...@gmail.com wrote: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13001+0+current/freebsd-performance Not being particularly passionate about any OS, I've been intrigued by the FreeBSD benchmarks. However, management is reluctant to use boxes which don't have

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Axel Rau
Am 05.10.2009 um 20:06 schrieb Karl Denninger: gjournal, no. ZFS has potential stability issues - I am VERY interested in it when those are resolved. It looks good on a test platform but I'm unwilling to run it in production; there are both reports of crashes and I have been able to

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Claus Guttesen
Claus Guttesen kome...@gmail.com wrote: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13001+0+current/freebsd-performance Not being particularly passionate about any OS, I've been intrigued by the FreeBSD benchmarks.  However, management is reluctant to use boxes which don't have

Re: [PERFORM] Speed / Server

2009-10-05 Thread Scott Marlowe
On Mon, Oct 5, 2009 at 7:30 AM, Nikolas Everett nik9...@gmail.com wrote: But you should plan on partitioning to multiple db servers up front and save pain of conversion later on.  A dual socket motherboard with 16 to 32 SAS drives and a fast RAID controller is WAY cheaper than a similar

Re: [PERFORM] Best suiting OS

2009-10-05 Thread Karl Denninger
Axel Rau wrote: Am 05.10.2009 um 20:06 schrieb Karl Denninger: gjournal, no. ZFS has potential stability issues - I am VERY interested in it when those are resolved. It looks good on a test platform but I'm unwilling to run it in production; there are both reports of crashes and I have

Re: Maybe OT, not sure Re: [PERFORM] Best suiting OS

2009-10-05 Thread Scott Marlowe
On Mon, Oct 5, 2009 at 6:35 AM, Adam Tauno Williams awill...@opengroupware.us wrote: Maybe - if the only thing the server is running is PostgreSQL. Show of hands - how many users who ONLY install PostgreSQL, and use a bare minimum OS install, choosing to not run any other software? Now, how

Re: [PERFORM] Distributed/Parallel Computing

2009-10-05 Thread Jeff Janes
On Mon, Oct 5, 2009 at 12:11 PM, Viji V Nair v...@fedoraproject.org wrote: Hi Team, This question may have asked many times previously also, but I could not find a solution for this in any post. any help on the following will be greatly appreciated. We have a PG DB with PostGIS functions.