Jean-Paul ARGUDO wrote:
>
> > I know with toast, block size is no longer an issue, but 8K is not a lot these
> > days, and it seems like a lot of syscall and block management overhead could be
> > reduced by doubling it. Any comments?
>
> IMHO, I think this would enhance performances only if tuple lenght is
> above 8k, huh?..
>
> I mean, I think this would enhance databases with many large objects. On
> the contrary, database with classical varchar and integers wont benefit
> it, don't you think?
See, I'm not sure. I can make many arguments pro or con, an I could defend
either, but my gut tells me that using 16K blocks will increase performance
over 8K. Aleady I have seen a sequential scan of a large table go from 20
seconds using 8K to 17.3 seconds using 16K.
select * from zsong where song like '%fubar%';
I am copying my pgbench database to the new block size to test that.
8K vs 16K
Pros:
A sequential scan will require 1/2 the number of system calls for the same
amount of data.
Block "cache" management costs will be cut in half, for the same amount of
data.
More index information per fetch.
Larger tuples can be stored without toasting.
Cons:
Time to search a block for a tuple may increase.
More memory used per block (These days, I don't think this is too much of an
issue.)
This is based on the assumption that reading an 8K chunk is about as costly as
reading a 16K chunk. If this assumption is not true, then the arguments do not
work.
