Hello Alvaro,
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.
Hmmm. Thanks for your point... indeed there may be implementation
details... not a surprise:-)
Note that I was more asking about the desirability of the feature, the
implementation is another, although also relevant, issue. To me it is
really desirable given the potential performance impact, but maybe we
should not care about 10%?
About your point: if we really have to do without dynamic stack allocation
(C99 is only 15, not ripe for adult use yet, maybe when it turns 18 or 21,
depending on the state:-), a possible way around would be to allocate a
larger area with some MAX_BLCKSZ with a ifdef for compilers that really
would not support dynamic stack allocation. Moreover, it might be possible
to hide it more or less cleanly in a macro. I had to put "-pedantic
-Werror" to manage to get an error on dynamic stack allocation with "gcc
-std=c89".
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
