Re: Fast insertion indexes: why no developments

<div dir="ltr"><div class="gmail_extra"><br /><div class="gmail_quote">On Wed, Oct 30, 2013 at 10:53 AM, Simon Riggs
<spandir="ltr"><<a href="mailto:simon@2ndquadrant.com" target="_blank">simon@2ndquadrant.com</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
id=":14o"style="overflow:hidden">LSM-tree also covers the goal of maintaining just 2 sub-trees and a<br /> concurrent
processof merging sub-trees. That sounds like it would<br /> take a lot of additional time to get right and would need
some<br/> off-line process to perform the merge.</div></blockquote></div><br /><br /></div><div class="gmail_extra">Not
necessarily.<br/><br /></div><div class="gmail_extra">Merging means applying insertions/deletions from one subtree to
another.While it's normally preferable and more efficient to do it in batches, I've successfully implemented in-memory
versionsthat use other writers to perform the task, amortizing the cost of merging across many operations. In essence,
whenthere's a need to merge two subtrees, an inserting process also merges one entry, so slowly trees get merged. That
worksin-memory very well, it's quite clear that it's not necessarily generalizable to external storage, but it's a
techniqueto have in mind.<br /><br /></div><div class="gmail_extra">Alternatively, vacuum could do it. It's quite
clearlya vacuuming task anyway.<br /><br /></div></div>