Recorder remote database options

No, I’ve not seen any history rendering issues since I went to Postgresql for Recorder. I did see extreme slow history rendering at times with recorder in native SQLite and some with Postgresql but only with HA running on Raspberry Pi. It was the frontend performance issue.
I forget what does your sensor config look like? And how much data? Also how loaded down in your HA server, if you shut down HA, restart and then immediately try the history view, does it come up?

This is probably the most talkie sensor on my HA, about 120,000 reading per day as you can see by query. But the history graph only takes at most 3 seconds to render. And I hit is a couple times to verify. I am on 16 gb SSD i7 mc mini Ubuntu 20 Postgresql 12.3 HA 2020.12.1 (see graphs below)



Thanks. I reduced the purge_keep_days figure and history now loads. It looks to me like it requests everything from the database then renders what it needs.

Is there any way to see what request was sent to or received by the database?

What HA config are you using for your database? do you record everything?

Here is my recorder related stuff in configuration.yaml , I do NOT exclude ANYthing from recorder, pictures of queries at bottom of post show number of state and event records per hour getting inserted into postgresql db, it looks like it averages about 40k records of each, so 80,000 records are being added to postgresql per hour:

# database
recorder:
    purge_keep_days: 65
    db_url: !secret postgres_url
    auto_purge: true


# Enables support for tracking state changes over time
history:

# View all events in a logbook
logbook:

I wonder if your recorder purge function is running wild???

I would review this guys bug report again. Text below where frenck closed this issue, as it goes off into MSSQL… so that part at end might not be relevant, but first part, I’m wondering if your database is still not setup in best way.

https://github.com/home-assistant/core/issues/44736
'The above seems to prevent timely removal of data, causing extensive time to run DELETE, second crashing this DELETE due to FK violations.
I run the following commands to remedy and alter DB structure, and after doing this deletes are successfully executed.'

show running queries in postgresql on homeassistant database

psql -U postgres -h 192.168.2.242
192.168.2.242 postgres@postgres=# select * from pg_stat_activity where datname='homeassistant';

Here is some stuff, if you want to do a comparison between my homeassistant postgresql database and yours. You could do a schema dump of your database and do a diff against the attach dump of my schema and see if you can see sometime significant. Ignore the ‘mikrotik_device_history’ table it has nothing to do with HA, and of course I have my archive tables, triggers, scripts and views, so ignore these differences.

pg_dump -U postgres -h <pgserver ipaddress> --create -s homeassistant > homeassistant_schema.sql

diff homeassistant_schema.sql daves_haschema.sql

You can create a HA test database from my schema or yours from stuff below…

You will need to your super admin postgresql account and pw to create a new test database.

pg_dump -U postgres -h 192.168.2.242 --create -s homeassistant > ha_schema.sql

Create a test copy of your home assistant database. You can edit this file and replace all instances of ‘homeassistant’ with something like ‘hatest’ to create a test environment. MAKE sure you get ALL of the references to ‘homeassistant’ there are some at the bottom.

psql -U postgres -h 192.168.2.242 --set ON_ERROR_STOP=on -f hatest.sql

You can ignore and drop the mikrotik_device_history table, it has nothing to do with HA and again, I have my archive stuff in there…

drop table mikrotik_device_history;

To remove the test database.

psql -U postgres -h 192.168.2.242
\l
drop database hatest;
\l

You can dump your current home assistant database schema with above command, the dump the schema of the test ha database from my schema and do a diff on the two schema dumps to see the differences. Picture below.

pg_dump -U postgres -h 192.168.2.242 --create -s homeassistant > homeassistant_schema.sql
pg_dump -U postgres -h 192.168.2.242 --create -s hatest > hatest_schema.sql

diff homeassistant_schema.sql hatest_schema.sql

1 Like

I don’t think I answered your question about how to visualize a query that home assistant does. See if this answers it:

In psql, I am using the \watch command to reexecute a query every second. The query is just showing the queries that are being executed against the homeassistant database.

So I started this running and then in browser, I opened up a history view for a temperature sensor. See query and picture of graph below.

Hope this is helpful.

HA seems to be doing a well formed query that only asks for the data in the range of the graph.

user@ubuntu-macmini2012:~$ psql -U postgres -h 192.168.2.242

select query from pg_stat_activity where datname='homeassistant';

\watch 1

 COMMIT
 COMMIT
 ROLLBACK
 COMMIT
 SELECT 1;
 SELECT states.domain AS states_domain, states.entity_id AS states_entity_id, states.state AS states_state, states.attributes AS states_attributes, states.last_changed AS states_last_changed, states.last_updated AS states_last_updated +
 FROM states                                                                                                                                                                                                                               +
 WHERE states.last_updated < '2021-01-10T21:04:45.298000+00:00'::timestamptz AND states.entity_id = 'sensor.backyard_govee_temperature' ORDER BY states.last_updated DESC                                                                  +
  LIMIT 1
 COMMIT
 SELECT 1;
 COMMIT
(9 rows)

1 Like

Wow, thanks for the detailed replies. That’ll take a bit of time to digest. I expect I’ll be back… :laughing:

Good luck, hope you get it solved! I think I forgot to upload my Home Assistant / Postgresql schema, here it is so you can compare:
HA Schema for Postgresql database

You can ignor the mikrotik table, and the *_archive tables and stuff are related to my history archive. I use a postgresql user of ‘user’ for HA connection and ownership of database, so change that as needed.

1 Like

I may have got to the bottom of this. I don’t think the schema was updating correctly.

On each restart I was seeing

2021-01-31 14:51:45 WARNING (Recorder) [homeassistant.components.recorder.migration] Database is about to upgrade. Schema version: 10
2021-01-31 14:51:45 INFO (Recorder) [homeassistant.components.recorder.migration] Upgrading recorder db schema to version 11
2021-01-31 14:51:45 DEBUG (Recorder) [homeassistant.components.recorder.migration] Looking up index ix_states_old_state_id for table states
2021-01-31 14:51:45 DEBUG (Recorder) [homeassistant.components.recorder.migration] Creating ix_states_old_state_id index
2021-01-31 14:51:45 WARNING (Recorder) [homeassistant.components.recorder.migration] Adding index `ix_states_old_state_id` to database. Note: this can take several minutes on large databases and slow computers. Please be patient!
2021-01-31 14:51:46 DEBUG (Recorder) [homeassistant.components.recorder] Connected to recorder database

and looking at the code, these seemed to be no check to see if the schema update had happened. I certainly was not getting the ‘completed’ log message.

I ended up dropping the database and recreating it, then letting recorder do it’s stuff.

I’ll wait a few days until the data fills up again, but my feeling is this will solve it.

Yes, when I did the 2021.1.5 upgrade I think, I saw these same messages in my HA log as it started. I was thinking ‘oh oh’, but I watched as it cranked away for maybe 5 minutes and then the startup of the remainder of HA continued. 60 million records in my states table at this point. I was more worried that the table mods they were doing was going to impact my ‘custom’ triggers in some way. But they continue to work without errors. picture of current indexes on states below

I hope your solution gets you stable on postgresql. I continue to be happy with it as my analytics db. It’s no blaze but runs solid with my ML workflows in juypterlab. Below is a plot of 9 months of a bluetooth temperature sensor I have been testing 4 million datapoints queries from the states_archive table of 250 billion records. It took about 10 minutes for the query and juypterlab to generate the graph. This is not a normal workflow I do with so many points, was just using to show ranges over seasons to someone.

It didn’t even pause for thought as it tripped through those actions so I don’t think anything happened.

I’m happy with the database solidity and the speed of restart (the native DB just isn’t up to it), just would like the history page to work :slight_smile: