<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 10, 2015 at 10:30 PM, Shrinand Javadekar <span dir="ltr"><<a href="mailto:shrinand@maginatics.com" target="_blank">shrinand@maginatics.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Has there been any analysis done of the cost incurred by<br>
this index?</blockquote><div><br></div><div><div>No formal analysis beyond some benchmarking back when gholt, redbo and wreese were trying to figure out what to do about crappy performance of listings (> 1000ms) on this one 4GB container with "only" a few thousand objects but millions of rows because it was being used as a work queue.  If you're offering to dig into it and publish some quantification I don't think you'd be duplicating any currently available material on the subject - knock yourself out.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
1. Having this index will slow down writes into the object table. But<br>
by how much?<br>
2. The index will use some disk space. How much?<br></blockquote><div><br></div><div>Yeah that's the thing.  It's not free, sure - but it's definitely cheaper than the name index - and w/o the name index I don't think prefix queries would work at all once you get a few hundred thousand objects in a container - much less a million or more.  Not sure what you hope to achieve - always better to know than not know?</div><div><br></div><div>OTOH, if you're really interested in the guts of swift's sqlite datastores it might be more interesting/useful to see if there's any room to help with container sharding [1] - I'm sure matt wouldn't mind a review on the spec, even if it's just typos and clarifications.  Either that or try again to see if sqlite's WAL auto checkpointing [2] actually works [3] on recent versions and improves throughput on container updates over the current .pending & batch insert trick [4].</div><div><br></div><div>1. <a href="https://blueprints.launchpad.net/swift/+spec/container-sharding">https://blueprints.launchpad.net/swift/+spec/container-sharding</a></div><div>2. <a href="https://www.sqlite.org/wal.html#ckpt">https://www.sqlite.org/wal.html#ckpt</a></div><div>3. <a href="https://github.com/openstack/swift/commit/ed69db162aa9daa84cc3c86aec0af0c3f840acf6">https://github.com/openstack/swift/commit/ed69db162aa9daa84cc3c86aec0af0c3f840acf6</a></div><div>4. <a href="https://github.com/openstack/swift/blob/master/swift/container/backend.py#L697">https://github.com/openstack/swift/blob/master/swift/container/backend.py#L697</a></div><div><br></div><div>Good luck!</div><div><br></div><div>-Clay</div></div></div></div>