On Fri, Jun 30, 2023 at 4:27 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> On 6/30/23 23:11, Andres Freund wrote:
> > ...
> >
> > If we really wanted to do this - but I don't think we do - I'd argue for
> > working on the buildsystem support to build the postgres binary multiple
> > times, for 4, 8, 16 kB BLCKSZ and having a wrapper postgres binary that just
> > exec's the relevant "real" binary based on the pg_control value. I really
> > don't see us ever wanting to make BLCKSZ runtime configurable within one
> > postgres binary. There's just too much intrinsic overhead associated with
> > that.
> >
>
> I don't quite understand why we shouldn't do this (or at least try to).
> IMO the benefits of using smaller blocks were substantial (especially
> for 4kB, most likely due matching the internal SSD page size). The other
> benefits (reducing WAL volume) seem rather interesting too.
If it's dynamic, we could also be able to add detection of the best
block size at initdb time, leading to improvements all around, say.
:-)
> Sure, there are challenges (e.g. the overhead due to making it dynamic).
> No doubt about that.
I definitely agree that it seems worth looking into. If nothing else,
being able to quantify just what/where the overhead comes from may be
instructive for future efforts.
David
