On Thu, 2009-09-17 at 16:26 +0100, Simon Riggs wrote:
> Just been looking again at the way FSM works. In fsm_search_avail() we
> essentially have just a single way for working out how to search the
> tree.
>
> Seems like it would be good to abstract this so that we can implement a
> number of FSM search strategies
>
> * (current) randomize - page selection encourages different backends to
> access different blocks, thus reducing block contention
>
> * cluster - page selection made based around selecting block with
> freespace nearest current block and we prefer keep-in-sequence to
> avoid-contention
Is the information about "current block" available to FSM search API, or
do we need to change the API for that ?
> * compact - page selection specifically attempts to find the lowest
> numbered blocks, so that the table will naturally shrink over time.
>
> These are not all mutually exclusive, suggested combinations would be
>
> randomize, randomize | cluster, randomize | compact
>
> So we don't give up the load spreading behaviour, we just apply the
> logic at lower levels of the tree only.
>
> VACUUM could set the FSM into FSMstrategy = compact when it notices that
> most of the free blocks are at lower end of table. Or explicitly set
> during VF replacement utility.
>
> FSMstrategy = cluster would be the default if clustering is enabled on a
> table.
>
> FSMstrategy can change via ALTER TABLE ... WITH (fsm_strategy = ...)
>
> --
> Simon Riggs www.2ndQuadrant.com
>
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability Services, Consulting and Training
