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