feat: add Database Information Dashboard

[jheredianet]

This is a new contribution. A dashboard which could be helpful to browse database information: size, number of records, indexes, and generic data on drives and charges.

Once this PR is accepted, I'll remove it from the Custom Grafana Dashboards repository.

[netlify]

✅ Deploy Preview for teslamate ready!

Name	Link
🔨 Latest commit	48c206a
🔍 Latest deploy log	https://app.netlify.com/sites/teslamate/deploys/67cae992b34e700008fc9410
😎 Deploy Preview	https://deploy-preview-4578--teslamate.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[swiffer]

Thanks adding it here, i like it, especially as teslamate is self-hosted giving users some insights is valuable!

[jheredianet]

Thanks, adding it here, i like it, especially as teslamate is self-hosted giving users some insights is valuable!
Thank you too for the contributions made to this and other dashboards in my Custom Dashboards repository.

[JakobLichterfeld]

Ty, much appreciated. Will test on slow HW before merging, as currently all dashboard queries are optimized to run on slow HW I would like to keep this state.

[swiffer]

Ty, much appreciated. Will test on slow HW before merging, as currently all dashboard queries are optimized to run on slow HW I would like to keep this state.

Thanks, should be fast as well but give it a try!

[JakobLichterfeld]

Will test on slow HW before merging

Table Name | Row count is a bit slow, but 3-5s is acceptable imo for a maintenance dashboard. First run on the query took about 12.8s which is aweful

[swiffer]

there seems to be no other way except counting rows for each table which indeed can be slow... row estimates could be used instead but these can be up to 10% off

SELECT reltuples::bigint
FROM pg_catalog.pg_class
WHERE relname = 'positions';

i would stick with what we have currently ?

[jheredianet]

there seems to be no other way except counting rows for each table which indeed can be slow... row estimates could be used instead but these can be up to 10% off

SELECT reltuples::bigint
FROM pg_catalog.pg_class
WHERE relname = 'positions';

i would stick with what we have currently ?

I would leave it as it is now.

[JakobLichterfeld]

i would stick with what we have currently ?

Me too, that's why I merged :-)