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

Re: New FSM allocation policy

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New FSM allocation policy
Date: 2008-08-29 09:26:44
Message-ID: 871w082muj.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:

> 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

Starting from an arbitrary block that would be on average a 16MB stripe. 

One idea, we could scan the rest of the current page and use the first match.

Another, given the way your tree structure works you can also descend the tree
with a "target" page. You can find the first page with enough free space after
the target page if there are any. (Take left branch if it's > target and has
enough free space else take right branch if there's enough free space else
take left branch).

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's On-Demand Production Tuning

In response to

Responses

pgsql-hackers by date

Next:From: Asko OjaDate: 2008-08-29 09:39:14
Subject: Re: Proposal: new border setting in psql
Previous:From: C├ędric VillemainDate: 2008-08-29 08:53:38
Subject: Re: Proposal: new border setting in psql

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