Re: Checking for missing heap/index files - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Checking for missing heap/index files
Date
Msg-id CAH2-Wz=L2SeVzx6mn83udRoRbmw0Rd5csqAd-qR-M9mdz8LDHQ@mail.gmail.com
Whole thread Raw
In response to Re: Checking for missing heap/index files  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Mon, Jun 13, 2022 at 4:15 PM Bruce Momjian <bruce@momjian.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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Checking for missing heap/index files
Next
From: David Fetter
Date:
Subject: Re: Finer grain log timestamps