| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com> |
| Subject: | Re: GUC for cleanup indexes threshold. |
| Date: | 2017-03-03 19:49:36 |
| Message-ID: | CAH2-WzkCOuPP3FWNhUD9h6cH_53vcupozpBdbydgpUezivv6fA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 3, 2017 at 11:37 AM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> Please verify my understanding of your thought process: We don't have
> to freeze indexes at all, ever, so if we see index bloat as a separate
> problem, we also see that there is no need to *link* index needs to
> the need for freezing. XID burn rate is a very bad proxy for how
> bloated an index may be. Besides, we already have a separate trigger
> for the thing that *actually* matters to indexes (the vacuum threshold
> stuff).
Another thing I wonder about: It would be okay to use the number of
unset freeze map bits as a reasonable proxy for how much bloat is in
the index the first time we vacuum. But, don't we then set the freeze
map bits, losing any record of having skipped indexes?
What mechanism exists that allows back-pressure to actually *build up*
over many vacuum anti-wraparound cycles, so that we slowly but surely
get around to actually vacuuming indexes at some point?
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2017-03-03 19:51:22 | Re: Logical Replication and Character encoding |
| Previous Message | Peter Eisentraut | 2017-03-03 19:47:20 | Re: Restricting maximum keep segments by repslots |