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

Re: FSM search modes

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Simon Riggs" <simon(at)2ndQuadrant(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "decibel" <decibel(at)decibel(dot)org>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Itagaki Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FSM search modes
Date: 2009-10-01 22:07:41
Message-ID: 4AC4E1DD020000250002B586@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote: 
 
> (Hm, so we might want to make the probability depend on
> max_connections?)
 
Without doing rigorous math on it, I'd guess that to prevent
contention among n connections you'd want the probably of resetting
the sweep to be about 1 / (n * 2).  That would mean you'd advance to
the nth page about 60.6% of the time without resetting the sweep.  For
less contention, 1 / (n * 4) would let you get to the nth page about
77.9% of the time.
 
> Maybe what we want is some bias against inserting in the last half
> or quarter of the table, or some such rule, rather than necessarily
> heading for the start of the relation.
 
I think it would make sense to just start using this once you get into
the last half or quarter of the free pages.  If you go with the last
quarter, then you might want to use a higher probability than I
suggested above, although that would tend to leave you with contention
when all the free space was in the last quarter.  I'd be inclined to
use something like the above probability and start using it at 50%.
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-10-01 22:17:20
Subject: Re: FSM search modes
Previous:From: Dimitri FontaineDate: 2009-10-01 22:02:28
Subject: Re: FSM search modes

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