[Yum-devel] [PATCH] Create indexes in yum-metadata-parser

[Florian Festi]

seth vidal wrote:
> On Wed, 2007-08-22 at 16:08 +0200, Tim Lauridsen wrote:
>> Florian Festi wrote:
>>> Tim Lauridsen wrote:
>>>> I did some basic testing of the current yum git HEAD vs. yum 3.2.2.
>>> Yes, current git head is a bit slower than 3.2.2. There is a simple 
>>> reason for that: Linear searches on disk are even slower than linear 
>>> searches in memory.
>>>
>>> In other words: We are still missing some indexes in the sqlite 
>>> database to really gain speed from the changes. For performance runs 
>>> you can temporary remove patch 
>>> 3c2621ba8f8070f24ad3e979f6bd1699f6f6b394 or readd 
>>> 42283902f929ac131cda7b3497ae047b497e02bc.
>>>
>>> There are two possible permanent solutions:
>>>
>>> Readd the patch mentions above and extend it that all indexes are 
>>> created if they are not present yet. I posted timings for creating 
>>> these indexes some weeks ago (2. Aug "Sqlite DB Indexes").
>>>
>>> As alternative or in addition we could patch yum-metadata-parser to 
>>> just add the needed indexes.
>>>
>>> I can provide patches for both as soon as there is a decision with 
>>> way(s) we want to go.
>>>
>>>
>> I added this
>> http://devel.linux.duke.edu/gitweb/?p=yum.git;a=commitdiff;h=42283902f929ac131cda7b3497ae047b497e02bc
>> It speed up things a lot, but makes yum load the metadata every time, 
>> because the index creation changes the checksum i think.
>> I we want to create the indexes locally, how do we know when to download 
>> the sqlite tarball from the repo ?
>>
> 
> I don't think we want to make them locally. For verification purposes
> it's a dicey proposition.
> 
> Think about this:
> 
> if we see that the sqlite file is changed - how do we know it was
> changed due to index generation and not due to someone mucking with our
> metadata?

While I belief it is possible to create the indexes in a sane way locally 
this would require some more thought. As we are only a few days before F8 
feature freeze modifying the metadata-parser is the best solution for now. 
We can easily revisit that topic later on - or stay with that.

Patch is attached and compiles. Can someone please check if it really works 
as I am heading home now?

Thanks

Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-more-indexes-filenames-dirnames-PRCO-name.patch
Type: text/x-patch
Size: 3088 bytes
Desc: not available
Url : http://lists.baseurl.org/pipermail/yum-devel/attachments/20070822/c0ecdaac/attachment.bin