Re: Calculation for Max_FSM_pages : Any rules of thumb? - Mailing list pgsql-general

From Decibel!
Subject Re: Calculation for Max_FSM_pages : Any rules of thumb?
Date
Msg-id 0407CAF1-6535-4AA5-9526-16C4285C5DD4@decibel.org
Whole thread Raw
In response to Re: Calculation for Max_FSM_pages : Any rules of thumb?  (Ow Mun Heng <Ow.Mun.Heng@wdc.com>)
List pgsql-general
On Nov 20, 2007, at 6:14 PM, Ow Mun Heng wrote:
> On Mon, 2007-11-19 at 08:24 -0500, Bill Moran wrote:
>> In response to Ow Mun Heng <Ow.Mun.Heng@wdc.com>:
>>>
>>> Even with the regular vacuuming and even a vacuum full ( on my
>>> test DB)
>>> I still see that perhaps something is wrong (from the below)
>>>
>>> (I got this gem from the mailling list archives)
>>> hmxmms=> SELECT
>>>     c.relname,
>>>     c.reltuples::bigint as rowcnt,
>>>     pg_stat_get_tuples_inserted(c.oid) AS inserted,
>>>     pg_stat_get_tuples_updated(c.oid) AS updated,
>>>     pg_stat_get_tuples_deleted(c.oid) AS deleted
>>> FROM pg_class c
>>> WHERE c.relkind = 'r'::"char"
>>> GROUP BY c.oid, c.relname, c.reltuples
>>> HAVING pg_stat_get_tuples_updated(c.oid) +
>>> pg_stat_get_tuples_deleted(c.oid) > 1000
>>> ORDER BY pg_stat_get_tuples_updated(c.oid) +
>>> pg_stat_get_tuples_deleted(c.oid) DESC;
>>>         relname        |  rowcnt  | inserted | updated | deleted
>>> -----------------------+----------+----------+---------+----------
>>>  tst_r                 | 11971691 |        0 |       0 | 22390528
>>> <--
>>>  pg_statistic          |     1465 |      280 |    7716 |      153
>>>  dr_ns                 |  2305571 |     1959 |       0 |     1922
>>>  pg_attribute          |     3787 |     1403 |     184 |     1292
>>>
>>> No matter how many times I vacuum/full the deleted number still
>>> doesn't
>>> go down.
>>
>> Are you sure you're interpreting that number correctly?  I took it to
>> mean a counter of the number of delete operations since server start.

Actually, it's not on server start; it's on stats reset. Which can
happen at server start depending on your config.

> You are right. This is definitely a snafu in my interpretation.
> After I
> restarted PG on the laptop, the numbers went away. So, then I'm
> confused
> as to why the above "gem" was provided as a means to see which tables
> needs more vacumming.


By itself it doesn't help; you need to track how many rows have been
updated or deleted since the last time you vacuumed. That, along with
the rowcount, will give you an idea of how much of the table is dead
space.
--
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828



Attachment

pgsql-general by date:

Previous
From: Erik Jones
Date:
Subject: Re: SQL design pattern for a delta trigger?
Next
From: Decibel!
Date:
Subject: Re: Rules slower than Dynamic SQL ?