Re: [DOCS] Documentation of pg_badkend_pid and stats functions
On Apr 12, 2007, at 7:54 AM, Jim Nasby wrote: Two questions: Why is pg_backend_pid documented with the stats functions (9.19 System Information Functions) seems more logical. Also, I can see mentioning the stats functions in the monitoring section, but shouldn't they actually be documented in with the rest of the functions? No comments? Does that mean if I write up a patch it'll be accepted? -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [DOCS] Documentation of pg_badkend_pid and stats functions
Jim Nasby wrote: > On Apr 12, 2007, at 7:54 AM, Jim Nasby wrote: > > Two questions: Why is pg_backend_pid documented with the stats > > functions (9.19 System Information Functions) seems more logical. > > > > Also, I can see mentioning the stats functions in the monitoring > > section, but shouldn't they actually be documented in with the rest > > of the functions? > > No comments? Does that mean if I write up a patch it'll be accepted? Yea, I was wondering about that. I think the best idea would be to reference the backend functions from the main functions page, rather than move them. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] row-level stats and last analyze time
Neil Conway <[EMAIL PROTECTED]> writes: > On Thu, 2007-26-04 at 18:07 -0400, Neil Conway wrote: >> (1) I believe the reasoning for Tom's earlier change was not to reduce >> the I/O between the backend and the pgstat process [...] > Tom, any comments on this? Your change introduced an undocumented > regression into 8.2. I think you're on the hook for a documentation > update at the very least, if not a revert. The documentation update seems the most prudent thing to me. The problem with the prior behavior is that it guarantees that every table in the database will eventually have a pg_stat entry, even if stats_row_level and stats_block_level are both off. In a DB with lots of tables that creates a significant overhead *for a feature the DBA probably thinks is turned off*. This is not how it worked before 8.2, and so 8.2.0's behavior is arguably a performance regression compared to 8.1 and before. Now this patch went in before we realized that 8.2.x had a bug in computing the stats-file-update delay, and it could be that after fixing that the problem is not so pressing. But I don't particularly care for new features that impose a performance penalty on those who aren't using them, and that's exactly what last_vacuum/last_analyze tracking does if we allow it to bloat the stats file in the default configuration. The long-term answer of course is to devise a more efficient stats reporting scheme, but I'm not sure offhand what that would look like. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
