On Tue, Jul 22, 2014 at 1:22 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Fabien wrote: >> ISTM that a desirable and reasonably simple to implement feature >> would be to be able to set the blocksize at "initdb" time, and >> "postgres" could use the value found in the database instead of a >> compile-time one. > > I think you will find it more difficult to implement than it seems at > first. For one thing, there are several macros that depend on the block > size and the algorithms involved cannot work with dynamic sizes; > consider MaxIndexTuplesPerPage which is used inPageIndexMultiDelete() > for instance. That value is used to allocate an array in the stack, > but that doesn't work if the array size is dynamic. (Actually it works > almost everywhere, but that feature is not in C89 and thus it fails on > Windows). That shouldn't be a problem, you say, just palloc() the array > -- except that that function is called within critical sections in some > places (e.g. _bt_delitems_vacuum) and you cannot use palloc there.
There's a performance argument here as well. Static allocation is likely faster that palloc, and there are likely many other places where having things like BLCKSZ or MaxIndexTuplesPerPage as compile-time constants saves a few cycles. A 10% speedup is nice, but I wouldn't want to pay 1% for everybody to get back 10% people who are willing to fiddle with the block size. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers