27.08.10, 14:38, "Ciaran McCreesh" <[email protected]>:

>  The search index becomes invalid after you change *anything*. If you
>  sync, it's invalid. If you install, upgrade, reinstall or uninstall
>  something, it's invalid. If you change any of your configuration files,
>  it's invalid.

Well, I thought about global index.
I mean that is under paludis full control.
Imho, doing installs/uninstalls from paludis/portage in the same time is not 
the right practice anyway.

Not sure about difficulties with configuration files.
Their size/format is not that big/complex compared to ebuilds/eclasses. But I 
am in no way an expert here.
  
>  There's no performance gain to be had from incremental updates after a
>  sync. After a sync, to build an index, every bit of metadata has to be
>  checked to see whether it's changed, which is where the time goes (and
>  the cost of removing a subset of invalid things and reinserting new
>  values into an SQLite table is pretty much the same as just rewriting
>  the entire thing from scratch).

Maybe some kind of check-sums for ebuilds + eclasses can be useful here?

>  It *would* be possible to avoid having to rebuild the entire index
>  after an install. Implementing something like 'cave manage-search-index
>  --reindex cat/pkg' wouldn't be very difficult. However, knowing which
>  packages to reindex isn't entirely trivial if any version or previously
>  existing version of the package in question is involved in virtuals in
>  some way.
>  Really, the only time it makes sense to use a search index is if you're
>  likely to run several searches one after another. Anything beyond that,
>  and the cost of keeping the search index up to date outweighs the gains
>  of having one at all -- inaccurate search results as given to you by
>  certain other programs are worse than useless...

I have ~20 Gentoo repositories with 32000 ebuild in total and it took me about 
two hours to build the index.
I can hardly imagine any number of queries for justifying such index rebuilds 
(besides some centralized search).

Again, maybe it worth doing some "light" information index storage?
I mean putting only more or less static information in db.

-- 
Regards,
Denis Golovan aka MageSlayer
_______________________________________________
paludis-user mailing list
[email protected]
http://lists.pioto.org/mailman/listinfo/paludis-user

Reply via email to