[tor-dev] Onionoo protocol/implementation nuances / Onionoo-connected metrics project stuff

[Kostas Jakeliunas]

It should also be possible to do efficient *estimated* COUNTs (using
reltuples [1, 2], provided the DB can be regularly VACUUMed + ANALYZEd
(postgres-specific awesomeness)) - i.e. if everything is set up right,
doing COUNTs would be efficient. This would be nice not only because one
could run very quick queries asking e.g. "how many consensuses include
nickname LIKE %moo% between [daterange1, daterange2]?" (if e.g. full text
search is set up) but also, if we have to resort to sometimes returning an
arbitrary subset of results (or sorted however we wish, but the sorting
being done already on a small subset of results, if that makes sense), we'd
be able to also supply info how many other results matching these
particular criteria there are, and so on. The usefulness of all this really
depends on intended use cases, and I suppose here some discussion could be
had who / how would an Onionoo system covering all / most of all the
descriptor+consensus archives and hopefully having an extended set of
filter / result options be used?

[1]: http://www.varlena.com/GeneralBits/120.php
[2]: http://wiki.postgresql.org/wiki/Slow_Counting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130729/a5ce3c27/attachment.html>