Resent: previous message was stalled because of a bad "From:".
>>> 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. [...]
>
> 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.
Yes, I agree that it would not make much sense to have such a feature with
a significant performance penalty for most people.
For what I have seen, ISTM that palloc can be avoided altogether either
with dynamic stack allocation when supported (that is in most cases?), or
maybe in some case by allocating larger safe area. In such case, the
"block size" setting would be a "max block size", and all valid block
sizes below (eg for 8 kB: 1, 2, 4 and 8 kB) would be allowed.
--
Fabien.
