Re: DB Tuning Notes for comment...

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