monitoring-stats.html is too impenetrable
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.6/monitoring-stats.html Description: There needs to be a tutorial page explaining how to use pg_stat_all_tables to find missing indexes, or maybe just an example on monitoring-stats.html which is hopelessly inaccessible to a non-expert. I would have never been able to figure out anything close to the solution at https://www.reddit.com/r/PostgreSQL/comments/e0rx8l/i_was_missing_a_single_index_and_omgf_everything/ from the existing docs. Thank you for your kind consideration of this request; please do not hesitate to send instructions for how to submit a pull request for this, as I would gladly do so. Best regards, -Jim
Re: monitoring-stats.html is too impenetrable
On Sun, Nov 24, 2019 at 09:31:58AM +, PG Doc comments form wrote: > There needs to be a tutorial page explaining how to use pg_stat_all_tables > to find missing indexes, or maybe just an example on monitoring-stats.html > which is hopelessly inaccessible to a non-expert. I would have never been > able to figure out anything close to the solution at > https://www.reddit.com/r/PostgreSQL/comments/e0rx8l/i_was_missing_a_single_index_and_omgf_everything/ > from the existing docs. Well, it may be as simple as that in some cases, but you also need to consider other parameters in more complex cases, like: - Actual CPU consumption done by backends. - Get stats about predicates (WHERE and JOIN clauses). - Physical disk access. - Anything else I don't have on top of my mind. > Thank you for your kind consideration of this > request; please do not hesitate to send instructions for how to submit a > pull request for this, as I would gladly do so. Best regards, -Jim The Postgres mailing lists are old-school regarding that, so pull requests sent to the git repository on github or such are not accepted. Sending an email with a patch would be just but fine, and here you would need to patch some of the *.sgml files in doc/. So if you have anything you'd like to get changed with fresh ideas, let's see how you would like things to change and then let's discuss about it. Thanks, -- Michael signature.asc Description: PGP signature
Re: documentation clarifications for "alter sequence" ?
On Thu, Nov 21, 2019 at 08:06:28PM +, PG Doc comments form wrote: > -- it would be helpful if this interaction/ relation were explicitly pointed > out, and why it behaves this way. ("MINVALUE cannot be greater than START > value" makes more sense to me, since minvalue is the thing I'm attempting to > alter. Or even "START value must be at least MINVALUE", if in fact that's > the limitation.) Project style is usually to avoid full sentences in user-facing error messages, so an improvement may be something like that: cannot set MINVALUE to be higher or equal than START value. However, these error messages are actually as they are per the state of the code, whose goal is to be kept simple. If you look at init_params() in sequence.c, what happens is that an initial state of the sequence is taken, and then the parameters specified in *all* the sub-clauses of the query update the state of the sequence. Finally all the parameters are cross-checked, so you cannot actually know which parameter is being set. Note that trying to guess what is getting set and to inform that with more error messages would not be that helpful either if trying to update both parameters at the same time. For example what would you do here? ALTER SEQUENCE goo MINVALUE 4 START 1; > -- "Any parameters not specifically set in the ALTER SEQUENCE command > retain their prior settings". OK, but this does not seem intuitive, at least > to me. What meaning or use does a min value have after a restart? It simply means that non-updated parameters are left as they are originally. And minvalue/maxvalue are used depending on if the sequence is ascending/descending if CYCLE is enabled. If NO CYCLE is used they are used as sanity checks. > Also, "setval function" is mentioned. A link to that would be helpful. You can say the same about currval, lastval and nextval, no? -- Michael signature.asc Description: PGP signature