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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
