Skip site navigation (1) Skip section navigation (2)

New FSM allocation policy

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: New FSM allocation policy
Date: 2008-08-29 07:40:23
Message-ID: 48B7A7E7.2040206@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
The way my rewritten FSM works at the moment is that pages are handed 
out of the FSM in random order, to spread the load of multiple backends 
to different pages. That's good for spreading the load, but it occurred 
to me while observing a test case that inserts a lot of rows to an 
almost empty table with plenty of free space, that that sucks for the 
case of a single backend populating a table. Currently, FSM will hand 
out pages in sequential order, so from OS point of view we're reading 
and writing the pages sequentially. If the pages are handed out in 
random order, we'll do random I/O instead.

Fortunately there's an easy fix for that. If we optimize 
RecordAndGetPageWithFreeSpace so that it will always return the next 
page if it has enough space, we'll be doing sequential I/O again. That's 
trivial as long as the next heap page is on the same FSM page, and 
probably not too hard even if it's not. If we limit this optimization to 
within the same FSM page, we'll effectively be filling fully a 32MB stripes

Thoughts?

I'm running more tests, and there's more issues that need discussion, 
but I'll start separate threads for each. I'll also post an updated 
patch separately.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2008-08-29 07:47:16
Subject: New FSM patch
Previous:From: Greg SmithDate: 2008-08-29 07:36:27
Subject: Re: Proposal: new border setting in psql

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group