Re: [PERFORM] Pgsql - Red Hat Linux - VS MySQL VS MSSQL

2003-07-14 Thread Shridhar Daithankar
On Monday 14 July 2003 01:21, Balazs Wellisch wrote: Unfortunatelly, compiling from source is not really an option for us. We use RPMs only to ease the installation and upgrade process. We have over a hundred servers to maintaine and having to compile and recompile software everytime a new

Re: [PERFORM] Dual Xeon + HW RAID question

2003-07-14 Thread Andrew Sullivan
On Sat, Jul 12, 2003 at 11:25:14AM -0700, Nikolaus Dilger wrote: Alexandre, Since you want the fastest speed I would do the 2 data disks in RAID 0 (striping) not RAID 1 (mirroring). Note that RAID 0 buys you nothing at all in redundancy. So if the point is to be able to recover from a disk

Re: [PERFORM] Pgsql - Red Hat Linux - VS MySQL VS MSSQL

2003-07-14 Thread Andrew Sullivan
On Sun, Jul 13, 2003 at 12:42:29PM -0700, Balazs Wellisch wrote: On Sun, 2003-07-13 at 01:35, Balazs Wellisch wrote: Note that I've read a couple of times from Tom Lane (one of the core team) that FKs are a serous performance drag, so I'd drop them after the s/w has been in production

Re: [PERFORM] Pgsql - Red Hat Linux - VS MySQL VS MSSQL

2003-07-14 Thread Andrew Sullivan
On Sun, Jul 13, 2003 at 12:51:02PM -0700, Balazs Wellisch wrote: Unfortunatelly, compiling from source is not really an option for us. We use RPMs only to ease the installation and upgrade process. We have over a hundred servers to maintaine and having to compile and recompile software

Re: [PERFORM] [SQL] Replacing a simple nested query?

2003-07-14 Thread Steve Wampler
On Sun, 2003-07-13 at 14:50, Steve Wampler wrote: I've got a simple nested query: select * from attributes where id in (select id from attributes where (name='obsid') and (value='oid00066')); that performs abysmally. I've heard this described as the 'classic WHERE IN' problem.

Re: [PERFORM] Pgsql - Red Hat Linux - VS MySQL VS MSSQL

2003-07-14 Thread Paul Thomas
On 13/07/2003 20:51 Balazs Wellisch wrote: [snip] So, does anyone here have any experience using RH AS and DB 2.1? Are RH still selling DB 2.1? I can't find it listed on their web site. -- Yes, it's available for free download. The documentation is here:

Re: [PERFORM] Tunning FreeeBSD and PostgreSQL

2003-07-14 Thread Richard Huxton
On Monday 14 Jul 2003 3:31 pm, Stephen Howie wrote: [snip] My problem is that I have not totally put my head around the concepts of the shmmax, shmmaxpgs, etc As it pertains to my current setup and the shared mem values in postgresql.conf. I'm looking for a good rule of thumb when

[PERFORM] Java Out-of-memory errors on attempts to read tables with millionsof rows

2003-07-14 Thread Rich Cullingford
Greetings, We have several tables (in a PG 7.3.3 database on RH Linux 7.3) with 2M+ rows (each row 300-400 bytes in length) that we SELECT into a JDBC ResultSet for display to the user. We expected that the driver would not actually transmit data from the database until the application began

Re: [PERFORM] Tunning FreeeBSD and PostgreSQL

2003-07-14 Thread Stephen Howie
Richard- That was very helpfull Thanks! I still would like some guidance on tunning FreeBSD (shmmax and shmmaxpgs). Do I need to even touch these settings? Stephen Howie There are two articles recently posted here: http://www.varlena.com/GeneralBits/ They should provide a good start. --

Re: [PERFORM] optimizer picks smaller table to drive nested loops?

2003-07-14 Thread Tom Lane
Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: However, it looks to me like the subquery-scan-outside plan probably is the faster one, on both my machine and yours. I get Woah, that's pretty whacky. It seems like it ought to be way faster to do a single sequential