Quoting "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
> Hmm - that first query needs to do a sort, so you might want to
> experiment with
> the sort_mem parameter
Oops - I mean work_mem...
---(end of broadcast)---
TIP 5: don't forget to increase your f
Quoting Harry Hehl <[EMAIL PROTECTED]>:
> Mark,
>
> (snippage)However I am still getting seq scans on indexes for other queries
>
> For example:
>
> select * from omfile where ( objectid in ( select distinct(ref_oid)
> from
> ts ) );
> objectid & ref_oid are non-unique indexes
> omimagefile
Hi Mischa,
You probably need to determine whether the bottleneck is cpu or disk (should be
easy enough!)
Having said that, assuming your application is insert/update intensive I would
recommend:
- mount the ufs filesystems Pg uses *without* logging
- use postgresql.conf setting fsync_method=fdat
It may be worth pricing up expansion options e.g. 256M or more.
The other path to consider is changing RAID5 -> RAID10 if your card supports it.
However, I would recommend reducing that shared_buffers setting and doing your
performance measurements *again* - before changing anything else. This is
A furthur thought or two:
- you are *sure* that it is Postgres that is slow? (could be Php...or your
machine could be out of some resource - see next 2 points)
- is your machine running out of cpu or memory?
- is your machine seeing huge io transfers or long io waits?
- are you running Php on th
Quoting Stephane Tessier <[EMAIL PROTECTED]>:
General parameter suggestions:
> shared_buffers = 128000 # min max_connections*2 or 16, 8KB each
> effective_cache_size = 196608 # typically 8KB each
Try reducing shared_buffers (say 3). There has been much discussion regards
setting t
