Re: parametric block size?

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