Re: Initdb-time block size specification
От | Tomas Vondra |
---|---|
Тема | Re: Initdb-time block size specification |
Дата | |
Msg-id | f4c7ad6a-802f-ed1f-6a33-6406999966a8@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Initdb-time block size specification (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Initdb-time block size specification
Re: Initdb-time block size specification |
Список | pgsql-hackers |
On 6/30/23 23:11, Andres Freund wrote: > Hi, > > ... > > I suspect you're going to see more benefits from going to a *lower* setting > than a higher one. Some practical issues aside, plenty of storage hardware > these days would allow to get rid of FPIs if you go to 4k blocks (although it > often requires explicit sysadmin action to reformat the drive into that mode > etc). But obviously that's problematic from the "postgres limits" POV. > I wonder what are the conditions/options for disabling FPI. I kinda assume it'd apply to new drives with 4k sectors, with properly aligned partitions etc. But I haven't seen any particularly clear confirmation that's correct. > > 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. > How would that work for extensions which may be built for a particular BLCKSZ value (like pageinspect)? regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: