From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parametric block size? |
Date: | 2014-07-24 16:57:43 |
Message-ID: | alpine.DEB.2.10.1407241845110.3626@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-07-24 17:22:07 | Re: PostgreSQL 9.2.7 on Power 8 / AIX 7.1 |
Previous Message | Tom Lane | 2014-07-24 16:51:09 | Re: Remove comment about manually flipping attnotnull |