| 1 |
Duncan wrote: |
| 2 |
> So I believe the cost to be quite reasonably managed, after all. |
| 3 |
> Benchmarks would of course be needed to demonstrate that, but I believe |
| 4 |
> it worth pursuing. |
| 5 |
> |
| 6 |
|
| 7 |
Agreed. Perhaps I'm just spoiled by RDBMS's at work or something, but |
| 8 |
it seems like we're trying to squeeze every ounce of speed out of a |
| 9 |
non-indexed flat file database and do everything we can to avoid |
| 10 |
actually putting all that metadata in something that actually is |
| 11 |
queryable no matter how lousy the final design ends up being. |
| 12 |
|
| 13 |
Expressing the package database as a set of flat files works nicely - |
| 14 |
especially with cvs/git/etc. Actually working with that data directly |
| 15 |
on a real system doesn't make sense at all. Index it once and then only |
| 16 |
open the flat files on the rare occasion that you actually need to |
| 17 |
install one of them. Such an index can be centrally distributed, or it |
| 18 |
could be maintained as packages are rsynced (and of course users should |
| 19 |
be able to update it on demand as well). |
| 20 |
|
| 21 |
When the speed of your package management system depends on the |
| 22 |
performance of find vs grep -r, you are doing something wrong. Neither |
| 23 |
works all that well. |
Archives