-
Notifications
You must be signed in to change notification settings - Fork 231
maintaining "unique dbnames" is too costly #525
Comments
@kmoppel @kmoppel-cognite can you throw some light on this, please? What is the purpose of such a schedule? |
I think this is only used to make sure that the drop-down menus in grafana dashboards, where you can select specific databases
|
Only one instance can now have the lock for admin.all_distinct_dbname_metrics maintenance. Not 100% perfect though as connections interrupts can still lead to multiple updates per day but still much more resource-friendly than current state. #525
Hey, Yes Julian is almost correct - new databases are though added immediately to the listing on detection. The proposed workaround should be a big improvement already I think - to make it 100% correct and resource friendly one should do some DDL on the "admin" schema and have some explicit lock structure and track last_modified. |
I will try to address this issue in the next releases. Meanwhile your quick fix may give us some time. Thanks @kmoppel-cognite |
@pashagolub Actually seems, for that 100% correct approach one could also use the existing |
On a productive pgwatch2 setup using timescaledb, maintining the list of unique dbnames is too taxing.
Every pgwatch2 daemon (of which I have one for every DB instance here, 24 in total) runs
UniqueDbnamesListingMaintainer
every 24 hours.This results in full scans of all metric tables, just to maintain the list of active dbnames.
Maybe there should be a way to ensure this maintaining is not done more often than necessary.
The text was updated successfully, but these errors were encountered: