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
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. |