Re: Fractal tree indexing

From: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fractal tree indexing
Date: 2013-02-13 16:10:25
Message-ID: 529CA4E9-9731-4D2D-A9B6-84D4FE53BCC4@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-02-13 16:20:26 Re: Fractal tree indexing
Previous Message Peter Eisentraut 2013-02-13 16:08:56 Re: [COMMITTERS] pgsql: Add noreturn attributes to some error reporting functions