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: | 1199223049.9558.267.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
2ndQuadrant http://www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Chernow | 2008-01-02 01:49:53 | Re: binary array and record recv |
Previous Message | Martijn van Oosterhout | 2008-01-01 21:20:17 | Re: Index Page Split logging |