From: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
---|---|
To: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | "Neil Conway" <neilc(at)samurai(dot)com>, "PostgreSQL Patches" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: pg_avd |
Date: | 2003-02-18 20:50:41 |
Message-ID: | 001101c2d78f$66fe9250$6d00a8c0@sales4 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
From: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
> The only question I have is whether there is any way to see how much
> free space is available for each relation, and whether this is an issue.
> Is there code that sees lots of inserts into a table and starts a
> vacuum on it to try to fill up the free space list? My concern is that
> without knowing how much free space is recorded, it might be hard to
> know if a vacuum is required.
Since there is currently no way to know about the status from the FSM from
the client side I didn't encorporate anything related to it.
I had thought about extending the stats system to show FSM information, but
I wasn't sure it's a good idea and I wasn't sure how to do it (not that good
when dealing with code in the backend yet...) . Thoughts anyone?
More generally speaking, everytime there is an update or a delete, free
space was created, so just by looking at the activity on the table we have a
rough idea if we need to vacuum. What we don't know is if a highly updated
table has exhausted it's FSM entries and would benifit from a vacuum to
repopulate the FSM.
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2003-02-18 20:53:49 | Re: pg_avd |
Previous Message | Bruce Momjian | 2003-02-18 19:40:42 | Re: postgres error reporting |