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: 21044.1254416103@sss.pgh.pa.us (view raw or flat)
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

Responses

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-2014 The PostgreSQL Global Development Group