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