> this is the best reason I've heard for making it a security document. I > wonder how much slower the 7.5k dbs scan proceeds when it has to look up > documents instead of linked objects? do you mind adding a doc-read to the > tight loop just to see what it does to performance? >
$ time curl http://localhost:5984/_all_dbs | wc -l % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 100k 0 100k 0 0 576 0 --:--:-- 0:02:57 --:--:-- 555 7397 real 2m57.811s user 0m0.000s sys 0m0.020s Alot more as expected. > > the 7.5k thing isn't important once we have a _dbs db, but the cost it will > expose as a benchmark will be proportional to the cost incurred on opening > any db for any operation, and thus significant. > True. Traversing the b-tree of _dbs to find if a particular doc exists, and then eventually insert it (which could imply re-balancing the tree from time to time) would take several disk accesses. Any other ideas on how to implement _all_dbs efficiently? cheers -- Filipe David Manana, [email protected] PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
