> To answer all the other mails now: Yes, it is a very slow box, PII
> with 300 MHz, 256MB RAM, W2K OS, the harddisk is very old & slow too,
> the HD Tach test says average 10 MB which is not too bad.
That would probably explain most of the problems then. With a HDD
upgrade you can probably atleast double the speed (of DB).
> I figured that running the same query on all rows instead of fetching
> only the first 100 last just few second longer, and when I execute it
> from a remote host it last only 20 seconds which is still slow, but I
> can live with that as long as I know that the box is simply too slow
> to act as a database server at all. I'll install a faster harddisk
> now, maybe that helps.
Ok, could you just for the fun of it try this in front of your query?
explain analyze
ex:
dbmail=# explain ANALYZE select * from messageblks;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------
Seq Scan on messageblks (cost=0.00..304.92 rows=1792 width=913)
(actual time=0.015..3.249 rows=1830 loops=1)
Total runtime: 4.527 ms
(2 rows)
Btw, I ran that from the psql console ('psql dbmail postgres').
That is on a Dual 1Ghz P3, 1gb ram, softraid-1 ide disks running
linux. So it's clearly a faster box, not enough to warrant SECONDS
in difference.
Oh, and btw.. 'cost' is _NOT_ the same as predicted 'time'.
If you run that with a few queries that uses a where clause, you
can immedeately see wether the db uses the indexes or not.
And it's also good for simple benchmarking of db schema.
Another thing I'd look into if I were you is the postgresql.conf
file. I did some benchmarketing(!) of dbmail with pgsql 7.4 and these
were the only settings I had to change from default that made a
positive difference.
shared_buffers = 15200 # min 16, at least max_connections*2, 8KB each
sort_mem = 65536 # min 64, size in KB
vacuum_mem = 65536 # min 1024, size in KB
That requires shared buffers of 122MB. To get that to work in
linux I added this line to the postgresql start script (in rc.d)
echo 256000000 > /proc/sys/kernel/shmmax
I realise now that these are more general pgsql tips than spesifics
to your problem Gerrit, but hopefully you learned something new.
-=Dead2=-