You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 5, 2022. It is now read-only.
On one occasion by looking at the sprocs/all page of pgObserver, I couldn't find the sproc that was actively called on the running database. The reason was, it was older than 2 APIs ago. The problem is, no newer versions of that sproc were called (the backend was still at the N-3 API version) and the data for it was missing altogether.
The limitations, AFAIK, are there for the case the when the sproc changes significantly over the time, the data for the older version becomes irrelevant. Another reason is to reduce the amount of data to process. I think we may still satisfy both those requirements if we only include the data for a sproc which is older than N-2 revisions of API if the following conditions are true:
the sproc belongs to at least N-8 API or later (if one API release corresponds to a single week, it's unlikely that we will be running anything older than 2 months).
there is no data for the calls of the sproc with the same name, but later API revisions.
the sproc was called recently (i.e. during past week)
In other words, if the sproc A exists in R8, R9, R10, R11 and R12 APIs, the latest one in the database is R12 and it was called with R8 and R10 versions only during the last week, then we do include data for R10 only, because there were no calls for R11 and R12.
If, on the other hand, the same sproc gets called with R11 and R12, then only those 2 revisions are included, discarding the other ones.
The text was updated successfully, but these errors were encountered:
Yes, I agree. Current logic of just blindly grabbing 2 latest schemas in case of numbered "API schemas" is error-prone and meant for our usual "happy" cases. What we could do immediately, is to just increase the limiting constant here. But correct solution would be to change the simple data grabbing so that some comparison on some last X schemas' callcounts is performed, comparing last PgObserver counts with current DB counts from pg_stat_user_functions and then including all schemas that show changes.
On one occasion by looking at the sprocs/all page of pgObserver, I couldn't find the sproc that was actively called on the running database. The reason was, it was older than 2 APIs ago. The problem is, no newer versions of that sproc were called (the backend was still at the N-3 API version) and the data for it was missing altogether.
The limitations, AFAIK, are there for the case the when the sproc changes significantly over the time, the data for the older version becomes irrelevant. Another reason is to reduce the amount of data to process. I think we may still satisfy both those requirements if we only include the data for a sproc which is older than N-2 revisions of API if the following conditions are true:
In other words, if the sproc A exists in R8, R9, R10, R11 and R12 APIs, the latest one in the database is R12 and it was called with R8 and R10 versions only during the last week, then we do include data for R10 only, because there were no calls for R11 and R12.
If, on the other hand, the same sproc gets called with R11 and R12, then only those 2 revisions are included, discarding the other ones.
The text was updated successfully, but these errors were encountered: