Steinar H. Gunderson wrote:
> On Fri, Jul 07, 2006 at 09:28:52PM -0400, Chris Hoover wrote:
>> You need to increase your fsm settings. The database is telling you it is
>> trying to store 177K+ pages, but you have only provided it with 20K. Since
>> these pages are cheap, I would set your fsm up
On Fri, Jul 07, 2006 at 09:28:52PM -0400, Chris Hoover wrote:
> You need to increase your fsm settings. The database is telling you it is
> trying to store 177K+ pages, but you have only provided it with 20K. Since
> these pages are cheap, I would set your fsm up with at least the following.
Whi
> William,
>
> You need to increase your fsm settings. The database is telling you it is
> trying to store 177K+ pages, but you have only provided it with 20K. Since
> these pages are cheap, I would set your fsm up with at least the following.
>
> max_fsm_pages 50
> max_fsm_relations 5000
>
On 7/7/06, William Scott Jordan <[EMAIL PROTECTED]> wrote:
Hi Jeff,Ah, okay. I see what information you were looking for. Doing aVACUUM on the full DB, we get the following results:INFO: free space map: 885 relations, 8315 pages stored; 177632 total
pages neededDETAIL
On Friday 07 July 2006 17:48, William Scott Jordan wrote:
> Hi Jeff,
>
> Ah, okay. I see what information you were looking for. Doing a
> VACUUM on the full DB, we get the following results:
>
>
> INFO: free space map: 885 relations, 8315 pages stored; 177632 total
>
Hi Jeff,
Ah, okay. I see what information you were looking for. Doing a
VACUUM on the full DB, we get the following results:
INFO: free space map: 885 relations, 8315 pages stored; 177632 total
pages needed
DETAIL: Allocated FSM size: 1000 relations + 2 pa
On Fri, 7 Jul 2006, William Scott Jordan wrote:
Hi Jeff,
We are running ANALYZE with the hourly VACUUMs. Most of the time the VACUUM
for this table looks like this:
INFO: vacuuming "public.event_sums"
INFO: index "event_sums_event_available" now contains 56121 row versions in
2256 pages
Hi Jeff,
We are running ANALYZE with the hourly VACUUMs. Most of the time the
VACUUM for this table looks like this:
INFO: vacuuming "public.event_sums"
INFO: index "event_sums_event_available" now contains 35669 row
versions in 1524 pages
DETAIL: 22736 index
On Fri, 7 Jul 2006, William Scott Jordan wrote:
Hi all!
Can anyone explain to me what VACUUM does that REINDEX doesn't? We have a
frequently updated table on Postgres 7.4 on FC3 with about 35000 rows which
we VACUUM hourly and VACUUM FULL once per day. It seem like the table still
slows to
> I'm trying to decide now if we need to include a daily REINDEX along
> with our daily VACUUM FULL, and more importantly I'm just curious to
> know why we should or shouldn't do that.
>
> Any information on this subject would be appreciated.
My understanding is that vaccum full frees all of th
Hi all!
Can anyone explain to me what VACUUM does that REINDEX doesn't? We
have a frequently updated table on Postgres 7.4 on FC3 with about
35000 rows which we VACUUM hourly and VACUUM FULL once per day. It
seem like the table still slows to a crawl every few weeks. Running
a REINDEX by i
11 matches
Mail list logo
