Re: [PERFORM] optimization ideas for frequent, large(ish) updates in frequently accessed DB?

2004-02-13 Thread Manfred Koizar
On Fri, 13 Feb 2004 01:58:34 +0100, "Marinos J. Yannikos" <[EMAIL PROTECTED]> wrote: >I'm looking for ideas that might improve the interactive performance of >the system, without slowing down the updates too much. IOW, you could accept slower updates. Did you actually try and throttle down the i

Re: [PERFORM] Disappointing performance in db migrated from MS SQL Server

2004-02-13 Thread Andrew Sullivan
On Thu, Feb 12, 2004 at 05:19:27PM -0500, Chris Ruprecht wrote: > what he's doing, this might be a bottleneck. I don't like the virtual memory > strategy of Linux too much and would rather increase this to 1 - 2 GB for the > Postgres DB - Specially since he's not running anything else on the mac

Re: [PERFORM] optimization ideas for frequent, large(ish) updates in frequently accessed DB?

2004-02-13 Thread Manfred Koizar
Marinos, while you are busy answering my first set of questions :-), here is an idea that might help even out resource consumption. On Fri, 13 Feb 2004 01:58:34 +0100, "Marinos J. Yannikos" <[EMAIL PROTECTED]> wrote: >begin transaction; > delete from t where id=5; > insert into t (id,...) valu

Re: [PERFORM] Disappointing performance in db migrated from MS SQL Server

2004-02-13 Thread Leon Out
All, thanks for your suggestions. I've tweaked my configuration, and I think I've squeezed a little more performance out of the setup. I also tried running several tests simultaneously against postgres and SQL Server, and postgres did much better with the heavy load. My new settings are: max_co

[PERFORM] Lengthy pg_restore and high iowait?

2004-02-13 Thread Leon Out
Courier NewHello again. I'm setting up a backup routine for my new db server. As part of my testing, I'm attempting to pg_restore a pg_dump'ed backup of my database. The database is about 4.3 GB, and the dump file is about 100 MB. I first did a schema-only restore, then started a data-only restore

Re: [PERFORM] Disappointing performance in db migrated from MS SQL Server

2004-02-13 Thread Vivek Khera
> "LO" == Leon Out <[EMAIL PROTECTED]> writes: LO> Josh, the disks in the new system should be substantially faster than LO> the old. Both are Ultra160 SCSI RAID 5 arrays, but the new system has LO> 15k RPM disks, as opposed to the 10k RPM disks in the old system. If you've got the time, try

Re: [PERFORM] Disappointing performance in db migrated from MS SQL

2004-02-13 Thread matt
> Josh, the disks in the new system should be substantially faster than > the old. Both are Ultra160 SCSI RAID 5 arrays, but the new system has > 15k RPM disks, as opposed to the 10k RPM disks in the old system. Spindle speed does not correlate with 'throughput' in any easy way. What controllers

Re: [PERFORM] Disappointing performance in db migrated from MS SQL Server

2004-02-13 Thread Vivek Khera
> "LO" == Leon Out <[EMAIL PROTECTED]> writes: LO> project. The results so far have been disappointing, with Postgres LO> performing queries in about the same time as SQL Server even though LO> Postgres is running on a dedicated box with about 4 times the clock LO> speed of the SQL Server box.

[PERFORM] slow GIST index creation

2004-02-13 Thread Rajesh Kumar Mallah
Greetings! Why does creation of gist indexes takes significantly more time than normal btree index. Can any configuration changes lead to faster index creation? query: CREATE INDEX co_name_index_idx ON profiles USING gist (co_name_index public.gist_txtidx_ops); regds mallah.