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

Reply via email to