Re: Bad performance for a 3000 rows table updated - Mailing list pgsql-novice

From Manfred Koizar
Subject Re: Bad performance for a 3000 rows table updated
Date
Msg-id 8s929v0l2kcv5vgc4tu3ao8adfm6nvh9j8@4ax.com
Whole thread Raw
In response to Re: Bad performance for a 3000 rows table updated  (<fred-pg@jolliton.com>(Frederic Jolliton))
Responses Re: Bad performance for a 3000 rows table updated  (fred-pg@jolliton.com (Frederic Jolliton))
List 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 by date:

Previous
From: John Gunther
Date:
Subject: calling C++ functions from PostgreSQL
Next
From: fred-pg@jolliton.com (Frederic Jolliton)
Date:
Subject: Re: Bad performance for a 3000 rows table updated