Re: FSM search modes

On Thu, Oct 1, 2009 at 3:23 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> We probably could do with more bias. For example, we still prefer pages
> close to the page we last inserted to, by searching for free space in
> the same FSM page first, before starting the search from the top of the
> tree. And of course, each backend tries first to insert to the last page
> it inserted to before even consulting the FSM. A mode to disable those
> behaviors might indeed be useful, along with the random reset.

The elephant in the room here is that if the relation is a million
pages of which 1-100,000 and 1,000,000 are in use, no amount of bias
is going to help us truncate the relation unless every tuple on page
1,000,000 gets updated or deleted. If the user doesn't have any
interest in doing anything to those tuples, nothing will ever happen.

And this is likely to come up a lot, because many tables have a core
of data that is rarely or never updated. For example, imagine that
90% of pages contain data that is updated regularly and 10% of pages
contain data that is rarely or never updated. If these are
distributed uniformly, we figure to hit one of the latter type within
10 pages or so, and then we're stymied.

...Robert