• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

home-assistant / home-assistant / 27659
94%

Build:
DEFAULT BRANCH: dev
Ran 05 Aug 2017 06:43AM UTC
Jobs 5
Files 276
Run time 8min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

pending completion
27659

push

travis-ci

balloob
<a href="https://github.com/home-assistant/home-assistant/commit/6e1785173">History query and schema optimizations for huge performance boost (#8748)

* Add DEBUG-level log for db row to native object conversion

This is now the bottleneck (by a large margin) for big history queries, so I&#39;m leaving this log feature in to help diagnose users with a slow history page

* Rewrite of the &quot;first synthetic datapoint&quot; query for multiple entities

The old method was written in a manner that prevented an index from being used in the inner-most GROUP BY statement, causing massive performance issues especially when querying for a large time period.

The new query does have one material change that will cause it to return different results than before: instead of using max(state_id) to get the latest entry, we now get the max(last_updated). This is more appropriate (primary key should not be assumed to be in order of event firing) and allows an index to be used on the inner-most query. I added another JOIN layer to account for cases where there are two entries on the exact same `last_created` for a given entity. In this case we do use `state_id` as a tiebreaker.

For performance reasons the domain filters were also moved to the outermost query, as it&#39;s way more efficient to do it there than on the innermost query as before (due to indexing with GROUP BY problems)

The result is a query that only needs to do a filesort on the final result set, which will only be as many rows as there are entities.

* Remove the ORDER BY entity_id when fetching states, and add logging

Having this ORDER BY in the query prevents it from using an index due to the range filter, so it has been removed.

We already do a `groupby` in the `states_to_json` method which accomplishes exactly what the ORDER BY in the query was trying to do anyway, so this change causes no functional difference.

Also added DEBUG-level logging... (continued)

64 of 64 new or added lines in 4 files covered. (100.0%)

23900 of 25491 relevant lines covered (93.76%)

2.81 hits per line

New Missed Lines in Diff

Lines Coverage ∆ File
1
100.0
homeassistant/components/history.py
4
100.0
homeassistant/components/recorder/migration.py
Jobs
ID Job ID Ran Files Coverage
1 27659.1 (TOXENV=lint) 05 Aug 2017 06:52AM UTC 0
Travis Job 27659.1
2 27659.2 (TOXENV=py34) 05 Aug 2017 06:43AM UTC 0
93.74
Travis Job 27659.2
3 27659.3 (TOXENV=py35) 05 Aug 2017 06:51AM UTC 0
93.74
Travis Job 27659.3
4 27659.4 (TOXENV=py36) 05 Aug 2017 06:51AM UTC 0
93.74
Travis Job 27659.4
5 27659.5 (TOXENV=requirements) 05 Aug 2017 06:46AM UTC 0
Travis Job 27659.5
Source Files on build 27659
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #27659
  • 6e178517 on github
  • Prev Build on dev (#27658)
  • Next Build on dev (#27708)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc