Re: Fractal tree indexing - Mailing list pgsql-hackers

From Atri Sharma
Subject Re: Fractal tree indexing
Date
Msg-id 529CA4E9-9731-4D2D-A9B6-84D4FE53BCC4@gmail.com
Whole thread Raw
In response to Re: Fractal tree indexing  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers

Sent from my iPad
.
>
> That makes no sense. I don't see any way to implement this in an opclass, and it wouldn't make sense to re-implement
thisfor every opclass anyway. 
>
> The basic idea of a fractal tree index is to attach a buffer to every non-leaf page. On insertion, instead of
descendingall the way down to the correct leaf page, the new tuple is put on the buffer at the root page. When that
bufferfills up, all the tuples in the buffer are cascaded down to the buffers on the next level pages. And recursively,
whenevera buffer fills up at any level, it's flushed to the next level. This speeds up insertions, as you don't need to
fetchand update the right leaf page on every insert; the lower-level pages are updated in batch as a buffer fills up. 
>
> As I said earlier, this is very similar to the way the GiST buffering build algorithm works. It could be applied to
anytree-structured access method, including b-tree, GiST and SP-GiST. 
>

Can we implement it in a generic manner then? I mean,irrespective of the tree it is being applied to,be it BTree,gist
orspgist? 

Another thing,in case of a large tree which is split over multiple pages, how do we reduce the cost of I/o to fetch and
rewriteall those pages? 

Atri


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [COMMITTERS] pgsql: Add noreturn attributes to some error reporting functions
Next
From: Tom Lane
Date:
Subject: Re: Fractal tree indexing