Hello Andres,
But further benchmarks sound like a good idea.
I've started running some benchmarks with pgbench, with varying block &
WAL block sizes. I've done a blog post on a small subset of results,
focussing on block size with SSDs and to validate the significance of the
figures found,
> Possibly stopping at the tablespace level might be more straightforward.
> To avoid messing up the pages in shared buffers we'd perhaps need
> something like several shared buffer pools - each with either its own
> blocksize or associated with a (set of) tablespace(s).
This is exactly how Ora
On Sat, Jul 26, 2014 at 1:37 PM, Fabien COELHO wrote:
>> And I don't see that as being warranted at this point. But further
>> benchmarks sound like a good idea.
>
> Yep. A 10% potential performance impact looks worth the investigation.
I wonder, though, whether this isn't using a crowbar where s
On 26/07/14 21:05, Andres Freund wrote:
More advanced features, but with much more impact on the code, would be to
be able to change the size at database/table level.
That'd be pretty horrible because the size of pages in shared_buffers
wouldn't be uniform anymore.
Possibly stopping at th
The basic claim that I'm making wrt to this benchmark is that there may
be a significant impact on performance with changing the block size,
thus this is worth investigating. I think this claim is quite safe,
even if the benchmark is not the best possible.
Well, you went straight to making i
On 2014-07-26 19:06:58 +0200, Fabien COELHO wrote:
> The basic claim that I'm making wrt to this benchmark is that there may be a
> significant impact on performance with changing the block size, thus this is
> worth investigating. I think this claim is quite safe, even if the benchmark
> is not th
The rationale, which may be proven false, is that with a SSD the
latency penalty for reading and writing randomly vs sequentially is
much lower than for HDD, so there is less insentive to group stuff in
larger chunks on that account.
A higher number of blocks has overhead unrelated to this t
Hi,
On 2014-07-26 12:50:30 +0200, Fabien COELHO wrote:
> >>The default blocksize is currently 8k, which is not necessary optimal for
> >>all setup, especially with SSDs where the latency is much lower than HDD.
> >
> >I don't think that really follows.
>
> The rationale, which may be proven false
Hello Andres,
The default blocksize is currently 8k, which is not necessary optimal for
all setup, especially with SSDs where the latency is much lower than HDD.
I don't think that really follows.
The rationale, which may be proven false, is that with a SSD the latency
penalty for reading
Hi,
On 2014-07-22 10:22:53 +0200, Fabien wrote:
> The default blocksize is currently 8k, which is not necessary optimal for
> all setup, especially with SSDs where the latency is much lower than HDD.
I don't think that really follows.
> There is a case for different values with significant impac
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
Fabien COELHO wrote:
Hi,
> 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 improveme
Resent: previous message was stalled because of a bad "From:".
ISTM that a desirable and reasonably simple to implement feature
would be to be able to set the blocksize at "initdb" time, and
"postgres" could use the value found in the database instead of a
compile-time one.
I think you will f
On Tue, Jul 22, 2014 at 1:22 PM, Alvaro Herrera
wrote:
> Fabien wrote:
>> ISTM that a desirable and reasonably simple to implement feature
>> would be to be able to set the blocksize at "initdb" time, and
>> "postgres" could use the value found in the database instead of a
>> compile-time one.
>
>
Hello Alvaro,
ISTM that a desirable and reasonably simple to implement feature
would be to be able to set the blocksize at "initdb" time, and
"postgres" could use the value found in the database instead of a
compile-time one.
I think you will find it more difficult to implement than it seems
Fabien wrote:
> ISTM that a desirable and reasonably simple to implement feature
> would be to be able to set the blocksize at "initdb" time, and
> "postgres" could use the value found in the database instead of a
> compile-time one.
I think you will find it more difficult to implement than it se
Hello devs,
The default blocksize is currently 8k, which is not necessary optimal for
all setup, especially with SSDs where the latency is much lower than HDD.
There is a case for different values with significant impact on
performance (up to a not-to-be-sneezed-at 10% on a pgbench run on SS
17 matches
Mail list logo
