On Wed, January 3, 2018 4:04 pm, Robert Haas wrote:
> On Wed, Jan 3, 2018 at 3:43 PM, Remi Colinet <remi.colinet@gmail.com>
> wrote:
>> Justifications are:
>
> I think this is all missing the point. If varying the block size (or
> whatever) is beneficial, then having it configurable at initdb is
> clearly useful. But, as Andres says, you haven't submitted any
> evidence that this is the case. You need to describe scenarios in
> which (1) a non-default blocksize performs better and (2) there's no
> reasonable way to obtain the same performance improvement without
> changing the block size.
(Note: I gather that "block size" here is the page size, but I'm not
entirely sure. So this detail might make my arguments moot :)
First, I do think there is a chicken-and-egg problem here. If you can't
vary the values except by re-compiling, almost no-one does. So you don't
get any benchmarks, or data.
And even if the author of the patch does this, he can only provide very
spotty data, which might not be enough to draw the right conclusions.
Plus, if the goal is to "select the optimal size" (as opposed to Remi's
goal, which seems to me os "make it easier to select the optimial size for
one system at hand"), you might not be able to do this, as the "optimial"
size is different for different conditions, but you can't try different
values if the value is compiled in...
Plus, isn't almost all advancement in computing that you replace "1 + 1"
with "x + y"? :)
So, I do think the patch has some merits, because at least it allows much
easer benchmarking. And if the value was configurable at initdb time, I
think more people would experiment and settle for their optimium. So for
me the question isn't here "does it benefit everyone", but "does it
benefit some, and what is the cost for others".
Plus, I stumbled just by accident over a blog post from Tomas Vondra[0]
from 2015, who seems to agree that different page sizes can be useful:
https://blog.pgaddict.com/posts/postgresql-on-ssd-4kb-or-8kB-pages
Me thinks the next steps would be that more benchmarks are done on more
distinct hardware to see what benefits we can see, and weight this against
the complexity the patch introduces into the code base.
Hope that does make sense,
Tels
[0]: Tomas, great blog, btw!
