| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Naoya Anzai <nao-anzai(at)xc(dot)jp(dot)nec(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Akio Iwaasa <aki-iwaasa(at)vt(dot)jp(dot)nec(dot)com>, "bench(dot)coffee(at)gmail(dot)com" <bench(dot)coffee(at)gmail(dot)com> |
| Subject: | Re: [Proposal] More Vacuum Statistics |
| Date: | 2015-05-29 16:55:28 |
| Message-ID: | CAMkU=1ySQOwXEbe4dWjZ1iEEDuotq_GscQngtVFQb0UjMaqTfw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 28, 2015 at 4:08 AM, Naoya Anzai <nao-anzai(at)xc(dot)jp(dot)nec(dot)com>
wrote:
>
> 2. Page visibility rate of each table
> There is no way to know how many page-bits are them of each tables stored
> in their visibility maps. If we can show this information, then we will be
> able to guess vacuum overhead for the table. For example, if this table is
> a
> very big table but page visibility rate is high, then we can advise
> pg-users
> that vacuum for this table will execute faster than they think by low I/O
> overhead.
> Furthermore, this information can also be used in order to inform pg-users
> about "real" index-only-scan usability.
>
Isn't this already pg_class.relallvisible?
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-05-29 17:14:18 | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
| Previous Message | Robert Haas | 2015-05-29 16:43:34 | Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |