Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
От | Robert Haas |
---|---|
Тема | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |
Дата | |
Msg-id | BANLkTinN6KrpcFDu-Ha0hCa6eN6hr4FYuA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, May 25, 2011 at 5:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, May 25, 2011 at 1:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Because the problem is not specific to TOAST tables. As things >>> currently stand, we will accept the word of an ANALYZE as gospel even if >>> it scanned 1% of the table, and completely ignore the results from a >>> VACUUM even if it scanned 99% of the table. This is not sane. > >> I agree that if VACUUM scanned 99% of the table, it's probably fine to >> use its numbers. It's also fine to use the numbers from ANALYZE, >> because those pages are chosen randomly. What bothers me is the idea >> of using a small *non-random* sample, and I'm not sure that >> incorporating possibly-bogus results slowly is any better than >> incorporating them quickly. > > The above is simply fuzzy thinking. The fact that ANALYZE looked at a > random subset of pages is *no guarantee whatsoever* that its results are > highly accurate. They might be more trustworthy than VACUUM's nonrandom > sample of a similar number of pages, but it doesn't hold even a little > bit of water to claim that we should believe ANALYZE completely and > VACUUM not at all even when the latter has looked at a significantly > larger sample of pages. I think you're arguing against a straw-man. > In any case, your line of thought doesn't help us for fixing the problem > with toast tables, because we aren't going to start doing ANALYZEs on > toast tables. Can we simply use a constant for tuple density on TOAST tables? > The bottom line here is that making use of stats we have is a lot better > than not making use of them, even if they aren't entirely trustworthy. http://dilbert.com/strips/comic/2008-05-07/ -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: