From: | Frank Wiles <frank(at)wiles(dot)org> |
---|---|
To: | Ron St-Pierre <rstpierre(at)syscor(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Table UPDATE is too slow |
Date: | 2004-08-31 18:46:19 |
Message-ID: | 20040831134619.4ead03b0.frank@wiles.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
On Tue, 31 Aug 2004 11:11:02 -0700
Ron St-Pierre <rstpierre(at)syscor(dot)com> wrote:
> Postgres 7.4.3
> debian stable
> 2 GB RAM
> 80 DB IDE drive (we can't change it)
>
> shared_buffers = 2048
> sort_mem = 1024
> max_fsm_pages = 40000
> checkpoint_segments = 5
> random_page_cost = 3
I agree with all of the follow ups that having indexes on every
column is a bad idea. I would remove the indexes from the
least searched upon 10-20 columns, as I'm sure this will help
your performance.
You mention that not having indexes on some of the columns because it
"may slow down user queries". I think you should investigate this and
make sure they are necessary. I've seen many an application, with far
more rows than you're dealing with, only need 1 or 2 indexes, even
when all (or most) columns could be searched.
Also, you should consider increasing your shared_buffers and probably
your sort memory a touch as well. This will help your overall
performance.
---------------------------------
Frank Wiles <frank(at)wiles(dot)org>
http://www.wiles.org
---------------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | Ron St-Pierre | 2004-08-31 18:47:59 | Re: cannot reach http:/archives.postgresql.org |
Previous Message | Ron St-Pierre | 2004-08-31 18:35:38 | Re: Table UPDATE is too slow |
From | Date | Subject | |
---|---|---|---|
Next Message | Steinar H. Gunderson | 2004-08-31 18:48:45 | Re: Table UPDATE is too slow |
Previous Message | Ron St-Pierre | 2004-08-31 18:35:38 | Re: Table UPDATE is too slow |