Re: Fast insertion indexes: why no developments

<div dir="ltr"><div class="gmail_extra"><br /><div class="gmail_quote">On Tue, Oct 29, 2013 at 1:10 PM, Peter Geoghegan
<spandir="ltr"><<a href="mailto:pg@heroku.com" target="_blank">pg@heroku.com</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Oct
29,2013 at 7:53 AM, Leonardo Francalanci <<a href="mailto:m_lists@yahoo.it">m_lists@yahoo.it</a>> wrote:<br
/></div><divclass="im">> I don't see much interest in insert-efficient indexes.<br /><br /></div>Presumably someone
willget around to implementing a btree index<br /> insertion buffer one day. I think that would be a particularly<br />
compellingoptimization for us, because we could avoid ever inserting<br /> index tuples that are already dead when the
deferredinsertion<br /> actually occurs.</blockquote></div><br /><br /></div><div class="gmail_extra">Well, that should
berelatively easy the way web mining does it (with inverted indexes).<br /><br />Have a small (presumably RAM-fitting)
stagingindex where inserts take place, and regularly dump it into the "master index", the rationale being that by the
timeyou dump it, it'll be more efficient to do many inserts at once for one, and there will be lots of dead tuples you
don'teven have to consider for two.<br /><br /></div><div class="gmail_extra">And when I say relatively easy, I mean it
inthe sense that it only needs careful juggling of existing data structures.<br /></div></div>