Re: Initdb-time block size specification - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Initdb-time block size specification
Date
Msg-id 20230630193942.szccd62xdtkddmr5@awork3.anarazel.de
Whole thread Raw
In response to Initdb-time block size specification  (David Christensen <david.christensen@crunchydata.com>)
Responses Re: Initdb-time block size specification
List pgsql-hackers
Hi,

On 2023-06-30 12:35:09 -0500, David Christensen wrote:
> As discussed somewhat at PgCon, enclosed is v1 of a patch to provide
> variable block sizes; basically instead of BLCKSZ being a compile-time
> constant, a single set of binaries can support all of the block sizes
> Pg can support, using the value stored in pg_control as the basis.
> (Possible future plans would be to make this something even more
> dynamic, such as configured per tablespace, but this is out of scope;
> this just sets up the infrastructure for this.)

I am extremely doubtful this is a good idea. For one it causes a lot of churn,
but more importantly it turns currently cheap code paths into more expensive
ones.

Changes like

> -#define BufHdrGetBlock(bufHdr)    ((Block) (BufferBlocks + ((Size) (bufHdr)->buf_id) * BLCKSZ))
> +#define BufHdrGetBlock(bufHdr)    ((Block) (BufferBlocks + ((Size) (bufHdr)->buf_id) * CLUSTER_BLOCK_SIZE))

Note that CLUSTER_BLOCK_SIZE, despite looking like a macro that's constant, is
actually variable.

I am fairly certain this is going to be causing substantial performance
regressions.  I think we should reject this even if we don't immediately find
them, because it's almost guaranteed to cause some.


Besides this, I've not really heard any convincing justification for needing
this in the first place.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: David Christensen
Date:
Subject: Re: Initdb-time block size specification
Next
From: Nathan Bossart
Date:
Subject: Should we remove db_user_namespace?