On Thu, Feb 16, 2017 at 10:41 AM, Robert Haas <robertmh...@gmail.com> wrote: >> 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.
Not getting to a second VACUUM where you might have otherwise can only be a problem to the extent that users are sensitive to not reclaiming disk space from indexes at the level of the FSM. It's not accurate to say that pages could be left "half dead" indefinitely by this patch, since that is something that lasts only as long as the first phase of B-Tree page deletion. In fact, the only possible problem is that pages are recyclable in principle, but that doesn't happen due to this new GUC. That isn't analogous to heap bloat at all, because it's not as if there are any downlinks or right links or left links pointing to the recyclable (fully deleted) pages; the previous key space *has* in fact been *fully* reclaimed. These pages are fully dead, and as such are out of the critical path of index scans entirely once the second phase finishes. (They only need to continue to physically exist because old index scans might follow a stale pointer). Note that there is an interlock against RecentGlobalXmin respected by VACUUM, that prevents this sort of recycling. I suspect that the restrictions on page deletion as opposed to page recycling is vastly more likely to cause pain to users, and that's not made any worse by this. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers