Re: Slow updates, poor IO

Поиск
Список
Период
Сортировка
Искать
От
Greg Smith
Тема
Re: Slow updates, poor IO
Дата
Msg-id
Pine.GSO.4.64.0809282125550.24903@westnet.com
Ответ на
Список
Дерево обсуждения
Slow updates, poor IO John Huttley <John@mib-infotech.co.nz>
Re: Slow updates, poor IO Alan Hodgson <ahodgson@simkin.ca>
Re: Slow updates, poor IO Andrew Sullivan <ajs@commandprompt.com>
Re: Slow updates, poor IO John Huttley <John@mib-infotech.co.nz>
Re: Slow updates, poor IO "Scott Marlowe" <scott.marlowe@gmail.com>
Re: Slow updates, poor IO John Huttley <John@mib-infotech.co.nz>
Re: Slow updates, poor IO Tom Lane <tgl@sss.pgh.pa.us>
Re: Slow updates, poor IO John Huttley <John@mib-infotech.co.nz>
Re: Slow updates, poor IO John Huttley <John@mib-infotech.co.nz>
Re: Slow updates, poor IO Greg Smith <gsmith@gregsmith.com>
Re: Slow updates, poor IO John Huttley <John@mib-infotech.co.nz>
Re: Slow updates, poor IO Dan Langille <dan@langille.org>
Re: Slow updates, poor IO John Huttley <John@mib-infotech.co.nz>
Re: Slow updates, poor IO "Scott Marlowe" <scott.marlowe@gmail.com>
Re: Slow updates, poor IO John Huttley <John@mib-infotech.co.nz>
Re: Slow updates, poor IO "Scott Marlowe" <scott.marlowe@gmail.com>
Re: Slow updates, poor IO "Scott Carey" <scott@richrelevance.com>
Re: Slow updates, poor IO "Scott Marlowe" <scott.marlowe@gmail.com>
Re: Slow updates, poor IO "Scott Marlowe" <scott.marlowe@gmail.com>
Re: Slow updates, poor IO Greg Smith <gsmith@gregsmith.com>
Re: Slow updates, poor IO John Huttley <John@mib-infotech.co.nz>
Re: Slow updates, poor IO Greg Smith <gsmith@gregsmith.com>
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.

> 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.

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.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-performance по дате отправления
От: John Huttley
Дата:
Сообщение: Re: Slow updates, poor IO
От: John Huttley
Дата:
Сообщение: Re: Slow updates, poor IO
FAQ