Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Date: 2018-04-17 18:13:57
Message-ID: CAH2-WzmvUxvSd0gpcq_HU0VUgyOqOVJPHTpP9J=-XRLd=QMk3g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 17, 2018 at 11:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> So rather than a klugy solution that only fixes
> VACUUM (and not very well, requiring user intervention and an unpleasant
> tradeoff), we ought to look at ways to avoid needing a whole-pool scan to
> find the pages belonging to one relation. In the past we've been able to
> skate by without a decent solution for that because shared buffers were
> customarily not all that big. But if we're going to start considering
> huge buffer pools to be a case we want to have good performance for,
> that's got to change.

Andres mentioned that he has prototyped an approach to buffer
management that uses a Radix tree, which is generally assumed to be
the right long-term fix.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-04-17 18:18:36 Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Previous Message Alvaro Herrera 2018-04-17 18:13:30 Re: Deadlock in multiple CIC.