On Thu, 2007-01-11 at 14:45 -0500, Tom Lane wrote: > Kim <kim@xxxxxxxxxx> writes: > > We were running on 8.1.1 previous to upgrading to 8.2, and yes, we > > definitely have a heafty pg_class. The inheritance model is heavily used > > in our schema (the results of the group by you wanted to see are down > > below). However, no significant problems were seen with vacs while we > > were on 8.1. > > Odd, because the 8.1 code looks about the same, and it is perfectly > obvious in hindsight that its runtime is about O(N^2) in the number of > relations :-(. At least that'd be the case if the stats collector > output were fully populated. Did you have either stats_block_level or > stats_row_level turned on in 8.1? If not, maybe the reason for the > change is that in 8.2, that table *will* be pretty fully populated, > because now it's got a last-vacuum-time entry that gets made even if the > stats are otherwise turned off. Perhaps making that non-disablable > wasn't such a hot idea :-(. > > What I think we need to do about this is > > (1) fix pgstat_vacuum_tabstats to have non-O(N^2) behavior; I'm thinking > of using a hash table for the OIDs instead of a linear list. Should be > a pretty small change; I'll work on it today. > > (2) Reconsider whether last-vacuum-time should be sent to the collector > unconditionally. > > Comments from hackers? It's not clear to me how this fix will alter the INSERT issue Kim mentions. Are those issues connected? Or are you thinking that handling stats in a tight loop is slowing down other aspects of the system? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
