>> 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.
