Re: Fast insertion indexes: why no developments

<div dir="ltr"><div class="gmail_extra"><br /><div class="gmail_quote">On Tue, Nov 5, 2013 at 5:30 PM, Claudio Freire
<spandir="ltr"><<a href="mailto:klaussfreire@gmail.com" target="_blank">klaussfreire@gmail.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">> Maybe there's value in minmax indexes for sequential data, but not for<br /> > random data, which is
thetopic of this thread.<br /><br /><br /></div>Well, of course, they're not magic pixie dust.<br /><br /> But is your
datareally random? (or normal?)</blockquote></div><br /></div><div class="gmail_extra">I think minmax indexes are more
akinto bitmap indexes. They will be very effective for columns with low-cardinality, especially for columns that are
veryclustered. In the extreme if all the values in some regions of the table are the same then minmax indexes would be
optimal.I wouldn't expect them to be very effective for a highly selective column that isn't well clustered.<br /><br
/></div><divclass="gmail_extra">It really sounds like you're describing a particular workload that btrees could just be
moreoptimized for. Buffering all inserts in memory and merging them into the btree lazily is actually something Heikki
hasproposed in the past. I'm not clear if that gets you all the benefits of the indexes you described or not but it
seemsto target the particular problem you're having.<br clear="all" /></div><div class="gmail_extra"><br />-- <br
/>greg<br/></div></div>