<div dir="ltr">It's really more filtering objects with deleted = 1. The index used to just be name - but that was not too efficient for sqlite when a container had a lot of deleted objects (it'd have to page through a bunch of deleted rows that matched the name index to apply the filter on delete = 0. Adding the index for deleted ment for container listings could skip loading a bunch of rows so that worked out better.<div><div><br></div><div>As for why the container listing have to track deleted objects as rows it's basically the same problem as being solved by tombstones at the object layer - except this is for container replication/consistency - which is needed for the container api requests and updates to the account layer.</div></div><div><br></div><div>-Clay</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 10, 2015 at 11:14 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I see that Swift creates an index on the object table on the columns<br>
(deleted, name) in the container server. Where part of Swift queries<br>
the database for names where 'deleted = true'?<br>
<br>
I thought when an object is deleted, Swift synchronously truncates the<br>
file and renames it with a .ts extension. Is that not enough to<br>
identify a deleted object?<br>
<br>
-Shri<br>
<br>
_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
</blockquote></div><br></div>