On Thu, Feb 16, 2017 at 6:17 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 15 February 2017 at 08:07, Masahiko Sawada <sawada.m...@gmail.com> wrote: >> It's a bug. Attached latest version patch, which passed make check. > > In its current form, I'm not sure this is a good idea. Problems... > > 1. I'm pretty sure the world doesn't need another VACUUM parameter > > I suggest that we use the existing vacuum scale factor/4 to reflect > that indexes are more sensitive to bloat.
I do not think it's a good idea to control multiple behaviors with a single GUC. We don't really know that dividing by 4 will be right for everyone, or even for most people. It's better to have another parameter with a sensible default than to hardcode a ratio that might work out poorly for some people. > 2. The current btree vacuum code requires 2 vacuums to fully reuse > half-dead pages. So skipping an index vacuum might mean that second > index scan never happens at all, which would be bad. Maybe. If there are a tiny number of those half-dead pages in a huge index, it probably doesn't matter. Also, I don't think it would never happen, unless the table just never gets any more updates or deletes - but that case could also happen today. It's just a matter of happening less frequently. I guess the question is whether the accumulation of half-dead pages in the index could become a problem before the unsetting of all-visible bits in the heap becomes a problem. If the second one always happen first, then we don't have an issue here, but if it's possible for the first one to become a big problem before the second one gets to be a serious issue, then we need something more sophisticated. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
