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%?
10% performance improvement sounds good, no doubt. What will happen to
performance for people with the same block size? I mean, if you run a
comparison of current HEAD vs. patched with identical BLCKSZ, is there a
decrease in performance? I expect there will be some, although I'm not
sure to what extent.
I do not understand the question. Do you mean to compare current 'compile
time set block size' vs an hypothetical 'adaptative initdb-time block
size' version, which does not really exist yet?
I cannot answer that, but I would not expect significant differences. If
there is a significant performance impact, this would be sure no good.
People who pg_upgrade for example will be stuck with whatever blcksz
they had on the original installation and so will be unable to benefit
from this improvement.
Sure. What I'm looking at is just to have a postmaster executable which
tolerates several block sizes, but they must be set & chosen when
initdb-ing anyway.
I admit I'm not sure where's the breakeven point, i.e. what's the loss
we're willing to tolerate. It might be pretty small.
Minimal performance impact wrt the current version, got that!
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
