From: Heikki Linnakangas <heikki@enterprisedb.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: pgsql-patches <pgsql-patches@postgresql.org>
Subject: Re: Relation forks & FSM rewrite patches
Date: Fri, 04 Jul 2008 12:27:55 +0300
Message-ID: <486DED1B.4020202@enterprisedb.com> (raw)
In-Reply-To: <1215161814.4051.36.camel@ebony.site>
References: <48651722.8020600@enterprisedb.com>
<1215161814.4051.36.camel@ebony.site>
Simon Riggs wrote:
> On Fri, 2008-06-27 at 19:36 +0300, Heikki Linnakangas wrote:
>
>> Here's an updated version of the "relation forks" patch, and an
>> incremental FSM rewrite patch on top of that. The relation forks patch
>> is ready for review. The FSM implementation is more work-in-progress
>> still, but I'd like to get some review on that as well, with the goal of
>> doing more performance testing and committing it after the commit fest.
>
> Hmmm, a 6000 line page with no visible documentation, readme, nor any
> discussion on -hackers that I'm aware of.
There is a readme in the patch, and there certainly has been discussion
on -hackers, see:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00415.php
where the current design is discussed for the first time.
User documentation is still to be done. There isn't anything to tune, or
anything that requires manual maintenance, so there isn't much to
document, though, except perhaps a chapter in the "Internals" part.
Here's an updated version of the patch. Changes:
- one bug has been fixed (I assumed that it's always safe to call
rightchild(x) on a parent node, but that was not always true for the
rightmost branch of the tree)
- there's some new debugging code.
- if we can't find a page with enough free space in search_avail after
starting from scratch 1000 times, give up. That shouldn't happen, but
see below.
There is still a nasty bug somewhere, probably related to locking :-(. I
ran DBT-2 with this, and after about 1h a FSM lookup goes into an
endless loop, hogging all CPU. I suspect that there's a bug somewhere so
that a change to the root node of a lower level FSM page isn't
propagated to the upper level FSM page for some reason. oprofile shows
that the endless loop happens in search_avail. This is why I added the
code to give up after 1000 tries, hoping to get some debugging output
the next time that happens.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: heikki@enterprisedb.com, simon@2ndquadrant.com
Subject: Re: Relation forks & FSM rewrite patches
In-Reply-To: <486DED1B.4020202@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox