From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Florian Helmberger <fh(at)25th-floor(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |
Date: | 2011-05-26 20:30:09 |
Message-ID: | 28829.1306441809@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Except that's not how it works. At least in the case of ANALYZE, we
> *aren't* counting all the tuples in the table. We're selecting a
> random sample of pages and inferring a tuple density, which we then
> extrapolate to the whole table and store. Then when we pull it back
> out of the table, we convert it back to a tuple density. The real
> value we are computing and using almost everywhere is tuple density;
> storing a total number of tuples in the table appears to be just
> confusing the issue.
If we were starting in a green field we might choose to store tuple
density. However, the argument for changing it now is at best mighty
thin; IMO it is not worth the risk of breaking client code.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-05-26 20:37:45 | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |
Previous Message | Kevin Grittner | 2011-05-26 19:50:04 | Re: COMMIT takes long time for read only transaction |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-05-26 20:37:45 | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |
Previous Message | Robert Haas | 2011-05-26 19:48:29 | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |