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

Re: FSM search modes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, decibel <decibel(at)decibel(dot)org>, 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 16:55:03
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> Yes, as Tom points out, this must be done with bias away from the very
> end of the table.

> I meant that we should start from the beginning of large spaces and that
> we shouldn't assume that all space worth filling is at start of
> relation.

Right.  One of the goals that FSM is trying to meet is ensuring that
different backends aren't trying to insert into the same page
concurrently, so as to reduce page-level contention.  So for example
it'd be a bad idea to adopt the really-dumb strategy of searching from
the start of the table for each request --- it'd funnel all the backends
to the same target page.  What we want is a behavior that is randomized
but tends to prefer pages towards the start rather than hitting all free
pages equally.  The btree precedent makes me suspect that quite a weak
preference would be sufficient.  So for example we might try resetting
the search to the start of the relation with probability 0.01.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2009-10-01 16:56:00
Subject: Re: Rejecting weak passwords
Previous:From: Euler Taveira de OliveiraDate: 2009-10-01 16:45:49
Subject: Re: Limit allocated memory per session

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