Greg Smith wrote:
On Mon, 29 Sep 2008, John Huttley wrote:
checkpoint _segments=16 is fine, going to 64 made no improvement.
You might find that it does *after* increasing shared_buffers. If the
buffer cache is really small, the checkpoints can't have very much
work to do, so their impact on performance is smaller. Once you've
got a couple of hundred MB on there, the per-checkpoint overhead can
be considerable.
Ahh bugger, I've just trashed my test setup.
I've settled on 64Mb shared memory since I've only got 1Gb or RAM and
the system impact of 256M is severe.
Also it uses FB-DIMMS which cost arm+leg+first born
It would be nice if thing like
* The effect of updates on indexed tables
* Fill Factor
* reindex after restore
Were mentioned in the 'performance' section of the manual, since
that's the part someone will go to when looking for a solution.
If you have to reindex after restore to get good performance, that
means what you should do instead is drop the indexes on the table
during the restore and then create them once the data is there. The
REINDEX is more aimed at when the system has been running for a while
and getting fragmented.
I thought that the pg_dump generated files did that, so I dismissed it
initially. Maybe I did a data only restore into an existing schema..
Unfortunately most of the people who know enough about those topics to
really do a good treatment of them are too busy fixing slow systems to
have time to write about it. There are many articles on this general
topic trickling out at
http://wiki.postgresql.org/wiki/Performance_Optimization you might
find valuable in addition to the manual.
An of course this is now in mail archive!
--
* Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD
