Tom,
I'm happy to see your attentions turning back to the FSM. I like the
design, but I do have a few suggestions, particularly about how to
handle oversubscription of the FSM.
1. When the FSM is oversubscribed and one is trying to decide which
pages to keep, remember that page info is stored
Tom Lane wrote:
Stephen Marshall <[EMAIL PROTECTED]> writes:
2. The histogram concept is a neat idea, but I think some reorganization
of the page information might make it unnecessary. Currently the FSM
pages are sorted by BlockNumber. This was particularly useful for
adding i
Stephen Marshall <[EMAIL PROTECTED]> writes:
> If I understand the concept correctly, the histogram will only be
> calculated when MultiRecordFreeSpace is called AND the FSM is
> oversubscribed. However, when it is called, we will need to calculate a
> histogram for, and potentially trim data f
I wrote:
> Stephen Marshall <[EMAIL PROTECTED]> writes:
>> If we sort the page info by available space, we could then use binary
>> search to find space thresholds when we are handling oversubscription.
> The list-of-chunks storage layout provides only limited traction for
> searching anyway, an
Robert Treat <[EMAIL PROTECTED]> writes:
> I think I was thinking that a given table will always report more pages
> than an index on that table, since tables can report 50% empty pages
> while indexes only report 100% empty pages. This would cause tables to
> generally be favored over indexes, eve
On Thu, 2003-02-27 at 11:00, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Now that indexes are getting some reporting, my understanding is an
> > index would report fewer pages overall than it's associated table, but
> > those pages would be completely empty. However, given that
Robert Treat <[EMAIL PROTECTED]> writes:
> Now that indexes are getting some reporting, my understanding is an
> index would report fewer pages overall than it's associated table, but
> those pages would be completely empty. However, given that they don't
> reported non-empty pages, the percentage
On Wed, 2003-02-26 at 15:54, Tom Lane wrote:
>
> Comments anyone?
>
Now that indexes are getting some reporting, my understanding is an
index would report fewer pages overall than it's associated table, but
those pages would be completely empty. However, given that they don't
reported non-empt
Stephen Marshall <[EMAIL PROTECTED]> writes:
> 1. When the FSM is oversubscribed and one is trying to decide which
> pages to keep, remember that page info is stored in groups of
> CHUNK_SIZE pages, where CHUNK_SIZE is current 32.
Right, oversubscription would actually need to be measured in ch
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Correct me if I'm wrong, but the FSM is only populated by vacuum, so there
> is no FSM information for any given table / database until it's vacuumed, in
> a long running production enviornment this may not be that important, but it
> could result
> PS: Another idea I'm toying with is to dump out the FSM contents at
> postmaster shutdown and reload them at restart, so that the FSM doesn't
> have to start from ground zero on every restart cycle. But that's
> independent of the management algorithm...
Correct me if I'm wrong, but the FSM is
11 matches
Mail list logo
