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

Re: Index Page Split logging

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Index Page Split logging
Date: 2008-01-01 21:30:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 2008-01-01 at 22:20 +0100, Martijn van Oosterhout wrote:
> On Tue, Jan 01, 2008 at 08:55:58PM +0000, Simon Riggs wrote:
> > On Tue, 2008-01-01 at 14:02 -0500, Tom Lane wrote:
> > > Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > > > If we could log *only* the insert that caused the split, rather than the
> > > > split itself, we would avoid that situation entirely.
> > > 
> > > How are you going to avoid the need to run user-defined functions
> > > (specifically, the btree comparison functions) during replay?
> > 
> > Seems like a good objection. Just exercising my lateral thought muscles.
> It seems to me you should be able to manage an intermediate version
> where (in for example GiST) you store the output of picksplit. i.e. you
> describe your split as: items A,B,C went to the left and the rest went
> to the right page. This would allow you to reconstruct the split
> completely without actually having to write all the data.

Yes, but you may have to handle recursive splits in the parent, so the
problem is not fully solved by that manoeuvre.

Perhaps we could do this only in cases where the parent is not split?

Hmm, starting to sound too far fetched for me now.

  Simon Riggs

In response to

pgsql-hackers by date

Next:From: Andrew ChernowDate: 2008-01-02 01:49:53
Subject: Re: binary array and record recv
Previous:From: Martijn van OosterhoutDate: 2008-01-01 21:20:17
Subject: Re: Index Page Split logging

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