Open Stack

Thanks Clay! Has there been any analysis done of the cost incurred by
this index? Specifically,

1. Having this index will slow down writes into the object table. But
by how much?
2. The index will use some disk space. How much?

Thanks in advance.
-Shri


On Tue, Mar 10, 2015 at 12:32 PM, Clay Gerrard <clay.gerrard at gmail.com> wrote:
> 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.
>
> 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.
>
> -Clay
>
> On Tue, Mar 10, 2015 at 11:14 AM, Shrinand Javadekar
> <shrinand at maginatics.com> wrote:
>>
>> Hi,
>>
>> I see that Swift creates an index on the object table on the columns
>> (deleted, name) in the container server. Where part of Swift queries
>> the database for names where 'deleted = true'?
>>
>> I thought when an object is deleted, Swift synchronously truncates the
>> file and renames it with a .ts extension. Is that not enough to
>> identify a deleted object?
>>
>> -Shri
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>