Re: Checking for missing heap/index files

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Checking for missing heap/index files
Date: 2022-06-13 23:59:06
Message-ID: CAH2-Wz=L2SeVzx6mn83udRoRbmw0Rd5csqAd-qR-M9mdz8LDHQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 13, 2022 at 4:15 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> I agree --- it would be nice, but might be hard to justify the
> engineering and overhead involved. I guess I was just checking that I
> wasn't missing something obvious.

I suspect that the cost of being sloppy about this kind of thing
outweighs any benefit -- it's a false economy.

I believe we ought to eventually have crash-safe relation extension
and file allocation. Right now we're held back by concerns about
leaking a large number of empty pages (at least until the next
VACUUM). If leaking space was simply not possible in the first place,
we could afford to be more aggressive in code like
RelationAddExtraBlocks() -- it currently has a conservative cap of 512
pages per extension right now. This would require work in the FSM of
the kind I've been working on, on and off.

Each relation extension is bound to be more expensive when the process
is made crash safe, obviously -- but only if no other factor changes.
With larger batch sizes per relation extension, it could be very
different. Once you factor in lock contention, then having fewer
individual relation extensions for a fixed number of pages may make
all the difference.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2022-06-14 00:05:45 Re: Finer grain log timestamps
Previous Message Bruce Momjian 2022-06-13 23:15:29 Re: Checking for missing heap/index files