Re: DB Tuning Notes for comment... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DB Tuning Notes for comment...
Date
Msg-id 21702.1039484368@sss.pgh.pa.us
Whole thread Raw
In response to Re: DB Tuning Notes for comment...  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: DB Tuning Notes for comment...
List pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
> Secondly, an empty database contains 98 tables, so the default setting of 
> max_fsm_pages to 100 is way too low.

Only 37 of them need FSM entries, but still a good point; we should
probably bump it up to 1000 to be more realistic.

> oddly (bug? edge behaviour?) doing two vacuums in a row results in the free 
> space being used.

I'm on my way out the door, so no time to think about what's actually
happening in the current code, but ideally I would think that when the
FSM doesn't have enough space, it should prefer to remember info about
rels with heavy update activity (which might be approximated by "rels
with lots of free space", but isn't really the same thing).  A VACUUM
done just after startup does not have any historical info to base this
decision on.  So it's not unreasonable for the system to make better
choices after it's been running awhile than when it's freshly booted.
I'm not sure that this is actually what's happening today, just pointing
out that I don't consider it a bug per se if the code behaves that way.
(The existing code does have some LRU effects, IIRC, but not sure
if they account for what you see.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: psql's \d commands --- end of the line for 1-character
Next
From: Scott Shattuck
Date:
Subject: Re: DB Tuning Notes for comment...