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 this for 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 descending all the way down to the 
> correct leaf page, the new tuple is put on the buffer at the root page. When 
> that buffer fills up, all the tuples in the buffer are cascaded down to the 
> buffers on the next level pages. And recursively, whenever a buffer fills up 
> at any level, it's flushed to the next level. This speeds up insertions, as 
> you don't need to fetch and 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 any tree-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 or spgist?

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 rewrite all those pages?

Atri

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to