[PERFORM] PostgreSQL data on a NAS device ?

2003-10-20 Thread Alexander Priem
Hi all, Does anyone have any experience with putting PostgreSQL data on a NAS device? I am asking this because a NAS device is much cheaper to set up than a couple of SCSI disks. I would like to use a relatively cheap NAS device which uses four IDE drives (7.200 rpm), like the Dell PowerVault

Re: [PERFORM] PostgreSQL data on a NAS device ?

2003-10-20 Thread Jeff
On Mon, 20 Oct 2003 09:12:35 +0200 Alexander Priem [EMAIL PROTECTED] wrote: I am asking this because a NAS device is much cheaper to set up than a couple of SCSI disks. I would like to use a relatively cheap NAS device which uses four IDE drives (7.200 rpm), like the Dell PowerVault 725N. The

Re: [PERFORM] PostgreSQL data on a NAS device ?

2003-10-20 Thread Alexander Priem
Thanks for your reply, Jeff. If we are going to use a NAS device for storage, then it will be attached through a gigabit ethernet connection. Fiber will not be an option, since that would negate the savings we can make by using an IDE NAS device instead of SCSI-RAID, fiber's pretty expensive,

Re: [PERFORM] PostgreSQL data on a NAS device ?

2003-10-20 Thread Alexander Priem
Even better than the four-disk NAS I mentioned earlier is the following: Promise UltraTrak RM8000. This is a so-called SCSI-to-IDE RAID system. Basically it's a RAID setup of eight IDE disks, using a hardware RAID engine, that's connected to (in this case) the PostgreSQL server via a SCSI

Re: [PERFORM] PostgreSQL data on a NAS device ?

2003-10-20 Thread Hannu Krosing
Alexander Priem kirjutas E, 20.10.2003 kell 16:04: Even better than the four-disk NAS I mentioned earlier is the following: Promise UltraTrak RM8000. This is a so-called SCSI-to-IDE RAID system. While you are at it, you could also check out http://www.3ware.com/ I guess one of these with

Re: [PERFORM] PostgreSQL data on a NAS device ?

2003-10-20 Thread Will LaShell
Hello Alexander, On Mon, 2003-10-20 at 06:04, Alexander Priem wrote: Even better than the four-disk NAS I mentioned earlier is the following: Promise UltraTrak RM8000. This is a so-called SCSI-to-IDE RAID system. Basically it's a RAID setup of eight IDE disks, using a hardware RAID engine,

[PERFORM] Performance weirdness with/without vacuum analyze

2003-10-20 Thread Harry Broomhall
It has been suggested to me that I resubmit this question to this list, rather than the GENERAL list it was originaly sent to. I asked earlier about ways of doing an UPDATE involving a left outer join and got some very useful feedback. This has thrown up a (to me) strange anomaly about

Re: [PERFORM] Performance weirdness with/without vacuum analyze

2003-10-20 Thread Josh Berkus
Harry, It has been suggested to me that I resubmit this question to this list, rather than the GENERAL list it was originaly sent to. I asked earlier about ways of doing an UPDATE involving a left outer join and got some very useful feedback. The query you posted will always be

Re: [PERFORM] PostgreSQL data on a NAS device ?

2003-10-20 Thread scott.marlowe
On Mon, 20 Oct 2003, Alexander Priem wrote: Hi all, Does anyone have any experience with putting PostgreSQL data on a NAS device? I am asking this because a NAS device is much cheaper to set up than a couple of SCSI disks. I would like to use a relatively cheap NAS device which uses

Re: [PERFORM] index file bloating still in 7.4 ?

2003-10-20 Thread Seum-Lim Gan
Hi Tom, Josh, We tried one more thing: with the table not being updated at all and we did vacuum. Each time a vacuum is done, the index file becomes bigger. This is probably what is contributing to the index file growing as well. Thanks. Gan At 11:04 am -0500 2003/10/20, Seum-Lim Gan wrote: Hi

Re: [PERFORM] index file bloating still in 7.4 ?

2003-10-20 Thread Tom Lane
Seum-Lim Gan [EMAIL PROTECTED] writes: We tried one more thing: with the table not being updated at all and we did vacuum. Each time a vacuum is done, the index file becomes bigger. It is not possible for plain vacuum to make the index bigger. VACUUM FULL possibly could make the index bigger,

Re: [PERFORM] index file bloating still in 7.4 ?

2003-10-20 Thread Tom Lane
Seum-Lim Gan [EMAIL PROTECTED] writes: [ successive outputs from VACUUM ANALYZE ] FWIW, I don't think your problem is really index bloat at all, it's more like too-many-dead-rows bloat. Note that the number of dead row versions is climbing steadily from run to run: DETAIL: 101802 dead row

[PERFORM] SRFs ... no performance penalty?

2003-10-20 Thread Josh Berkus
Folks, I'm working on the demo session for our upcoming presentation at PHPCon. As a side issue, we ended up comparing 3 versions of the same search screen: 1) All in PHP with views; 2) Using a function to build a query and count results but executing that query directly and sorting, paging

Re: [PERFORM] Low Insert/Update Performance

2003-10-20 Thread Hannu Krosing
Rhaoni Chiu Pereira kirjutas E, 20.10.2003 kell 17:13: Hi List, I got a P4 1.7Ghz , 512MB RAM , HD 7200 RPM, on RED HAT 9 running PostgreSQL 7.3.2-3 Database. I have a Delphi aplication that updates the Oracle database using .dbf file's information ( converting the data from the

[PERFORM] Low Insert/Update Performance

2003-10-20 Thread Rhaoni Chiu Pereira
Hi List, I got a P4 1.7Ghz , 512MB RAM , HD 7200 RPM, on RED HAT 9 running PostgreSQL 7.3.2-3 Database. I have a Delphi aplication that updates the Oracle database using .dbf file's information ( converting the data from the old clipper aplication ) and it takes about 3min and 45

Re: [PERFORM] Low Insert/Update Performance

2003-10-20 Thread Jeff
On Mon, 20 Oct 2003 12:13:26 -0200 Rhaoni Chiu Pereira [EMAIL PROTECTED] wrote: Hi List, I got a P4 1.7Ghz , 512MB RAM , HD 7200 RPM, on RED HAT 9 running PostgreSQL 7.3.2-3 Database. [clip] Please send schema queries or we will not be able to help you. Also, if you could provide

Re: [PERFORM] Low Insert/Update Performance

2003-10-20 Thread Josh Berkus
Rhaoni, My problem is that I must substitute this Oracle for a PostgreSQL database and this same Delphi aplication takes 45 min to update Jan/2003. All delphi routines are converted and optmized to work with PgSQL. Obviously not. How about posting the update queries? -- Josh