Re: Possible TODO item? VACUUM on empty table
От | Tom Lane |
---|---|
Тема | Re: Possible TODO item? VACUUM on empty table |
Дата | |
Msg-id | 10380.1101494914@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Possible TODO item? VACUUM on empty table (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
Greg Stark <gsstark@mit.edu> writes: > But not all of the stats are simple totals. I'm not sure this would make sense > for the histogram arrays. Yeah, I don't know how you "halve" a histogram. But the problem is not with the pg_statistic stats, I think. It is already true that ANALYZE punts without touching pg_statistic if it was unable to find any live rows, and AFAIR it always has. So the problem case of delete all/analyze doesn't clobber pg_statistic. The issue is only with the relpages and reltuples counts in pg_class. I already have a proposal on the table to get rid of these in favor of a "tuples per page" entry, see eg http://archives.postgresql.org/pgsql-general/2004-08/msg01422.php An objection that I forgot to mention in that message is that any such change would break autovacuum in its current form; although that issue largely vanishes if we integrate autovacuum into the backend, and in any case we could offer a built-in function to return the current number of pages in a table. regards, tom lane
В списке pgsql-hackers по дате отправления: