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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
