"'John Kline' via weewx-user" <[email protected]> writes:
> The warm figure is the interesting one: 2.64 s wall, with user+sys > accounting for essentially all of it. Once the 242 MB is cached, the > cost is pure CPU — SQLite examining every row in the table. Storage > speed stops mattering; that 2.6 s is the floor on that hardware no > matter what the database sits on. Yes, except that 242 MB is a very high fraction of system memory, and reading that into cache is surely displacing other caching uses, resulting in other things having to be read later, when maybe they wouldn't. But that's very tricky to assess. I therefore think that the true cost should be viewed somewhere in between the cold and warm cases. The RPI3 I tested on runs weewx, only (VP2/5minutes). Classic skin x2 (Fred Flintstone units and metric), and mqtt publisher. Plus a few small system daemons. I reran the query this morning: sqlite> SELECT dateTime, pm2_5 FROM archive WHERE pm2_5 IS NOT NULL ORDER BY dateTime DESC LIMIT 1; Run Time: real 17.837007 user 1.703541 sys 1.534109 which shows that most of weewx.sdb is no longer cached. [Agreed that a query that has to sequential scan is not ok, when a bounded query will result in the same semantics in the end.] > Your outTemp comparison is the cleanest demonstration in this thread, > incidentally. Same query shape, same table, 30,000× difference — and > the only variable is whether the first row examined has a value in it. It just seemed like an obvious thing to run.... -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/weewx-user/rmiecgcbyfd.fsf%40s1.lexort.com.
