Re: New IndexAM API controlling index vacuum strategies

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New IndexAM API controlling index vacuum strategies
Date: 2021-03-09 20:35:01
Message-ID: CAH2-Wzk1SbLQd9R3YRKB3gjmB9Uze8re+4HQYTcxd6xQzjaiWA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 8, 2021 at 7:34 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> > One possible
> > consequence that I'm concerned about is sequential scan performance.
> > For an index scan, you just jump to the line pointer you want and then
> > go get the tuple, but a sequential scan has to loop over all the line
> > pointers on the page, and skipping a lot of dead ones can't be
> > completely free. A small increase in MaxHeapTuplesPerPage probably
> > wouldn't matter, but the proposed increase of almost 10x (291 -> 2042)
> > is a bit scary.
>
> I agree. Maybe the real problem here is that MaxHeapTuplesPerPage is a
> generic constant. Perhaps it should be something that can vary by
> table, according to practical table-level considerations such as
> projected tuple width given the "shape" of tuples for that table, etc.

Speaking of line pointer bloat (and "irreversible" bloat), I came
across something relevant today. I believe that this recent patch from
Matthias van de Meent is a relatively easy way to improve the
situation:

https://www.postgresql.org/message-id/flat/CAEze2WjgaQc55Y5f5CQd3L%3DeS5CZcff2Obxp%3DO6pto8-f0hC4w%40mail.gmail.com

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2021-03-09 20:51:45 Re: WIP: BRIN multi-range indexes
Previous Message Peter Geoghegan 2021-03-09 20:22:25 Re: Lowering the ever-growing heap->pd_lower