> > >> I'm pondering doing the same, but I'm not 100% sure there won't
> > >> be any dump/restore-required changes to it before it goes gold.
> > >> From my tuning tests I've been running on it, it appears to be
> > >> extremely fast and stable.
> >
> > sm> Yeah, right now it's looking like the only thing you'll have to do is
> > sm> reindex hash indexes between beta2 and beta3.
> >
> > Sean had grumbled something about making pagesize 16k on FreeBSD
> > for 7.4 but it seems unlikely. I'll just locally patch it since
> > it does seem to offer some improvement.
>
> Without a fair amount of testing, especially on other platforms, it
> most likely won't happen in the distribution itself ... one of the
> things that was bantered around for after v7.4 is released is seeing
> how increasing it on the various platforms fairs, and possibly just
> raising the default to 16k or 32k (Tatsuo mentioned a 15%
> improvement at 32k) ...
>
> But, we'll need broader testing before that happens ...
I haven't had a chance to sit down and do any exhaustive testing yet
and don't think I will for a while. That said, once 7.4 goes gold,
I'm going to provide databases/postgresql-devel with a tunable that
will allow people to choose what block size they would like (4k, 8K,
16K, 32K, or 64K) when they build the port. Hopefully people will
chime in with their results at that time. With things so close to 7.4
and Tom worried about digging up possible bugs, I'm not about to
destabilize 7.4 for FreeBSD users.
I'm personally under the gut feeling that 8K or 4K block sizes will be
a win for some loads, but bigger block sizes will result in more
efficient over all operations in cases where IO is more expensive than
CPU (which changes with hardware and workload).
In the future table spaces implementation, I think it would be a HUGE
win for DBAs if the block size could be specified on a per table
basis. I know that won't be an easy change, but I do think it would
be beneficial for different work loads and filesystems.
-sc
--
Sean Chittenden
