Re: Bad performance for a 3000 rows table updated

Поиск
Список
Период
Сортировка
От Manfred Koizar
Тема Re: Bad performance for a 3000 rows table updated
Дата
Msg-id 8s929v0l2kcv5vgc4tu3ao8adfm6nvh9j8@4ax.com
обсуждение исходный текст
Ответ на Re: Bad performance for a 3000 rows table updated  (<fred-pg@jolliton.com>(Frederic Jolliton))
Ответы Re: Bad performance for a 3000 rows table updated  (fred-pg@jolliton.com (Frederic Jolliton))
Список pgsql-novice
On Sat, 05 Apr 2003 23:38:25 +0200, <fred-pg@jolliton.com>(Frederic
Jolliton) wrote:
>I don't know exactly how to pick a good value for MAX_FSM_PAGES.

If you have only two active tables and with the size you reported, the
defaults should be sufficient.  FSM settings have been discussed in
more deatil before.  Search the archives for details.

>SELECT relname,relpages [...]
>
>give 156 for the main table, doing a VACUUM every minute,

Is this number stable or always increasing?  If the latter, how fast
is it growing?  VACUUM (without FULL) never truncates a relation.
When your relation size gets out of control, do a VACUUM FULL to
restore a sane state.

> then after a
>VACUUM FULL give 52 (and a initial value of 10 when benching from a
>clean database.)

This initial value is only an assumption and has nothing to do with
the real size.  relpages is not accurate at every moment, AFAIK it is
updated only by some administrative commands (VACUUM, ANALYSE, CREATE
INDEX, etc).

Servus
 Manfred


В списке pgsql-novice по дате отправления:

Предыдущее
От: John Gunther
Дата:
Сообщение: calling C++ functions from PostgreSQL
Следующее
От: fred-pg@jolliton.com (Frederic Jolliton)
Дата:
Сообщение: Re: Bad performance for a 3000 rows table updated