Skip to content
This repository has been archived by the owner on Dec 5, 2022. It is now read-only.

Ignore the 'recent 2 API schemas' rule for sprocs if newer version of them were not called yet #47

Open
alexeyklyukin opened this issue Apr 28, 2015 · 3 comments

Comments

@alexeyklyukin
Copy link
Contributor

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.

@kmoppel
Copy link
Contributor

kmoppel commented Apr 28, 2015

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.

kmoppel pushed a commit that referenced this issue Apr 28, 2015
@kmoppel
Copy link
Contributor

kmoppel commented Apr 28, 2015

Changed the constant from 2 to 4 (last schemas) now. 284d3b4

@lasomethingsomething
Copy link
Contributor

Hey @alexeyklyukin, can we close this issue? It dates back to April 2015.

Or, we could add a "Help Wanted" label.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants