Marc G. Fournier wrote:
Now, here's a question for someone running a non-FreeBSD OS ... if we were
to jump the BLCKSZ to 16k, would it cause a degradation in performance, or
would it make no difference to them? Would they see an 8% reduction in
performance?
The thing is ... there has been
Early performance tests on my laptop suggest it's about 8%
faster for writing when both the FS and PostgreSQL use 16K
blocks.
BTW, I don't really believe that one set of tests, conducted on
one single machine, are anywhere near enough justification for
changing this value.
On Thu, Aug 28, 2003 at 01:00:44PM -0700, Sean Chittenden wrote:
Other than you feeling uneasy about the possibility of uncovering bugs
because this hasn't been widely done like this before, do you have any
other concerns, or do you think the possibility of finding bugs very
likely?
In case
On Thu, 28 Aug 2003, Neil Conway wrote:
On Thu, Aug 28, 2003 at 01:00:44PM -0700, Sean Chittenden wrote:
Other than you feeling uneasy about the possibility of uncovering bugs
because this hasn't been widely done like this before, do you have any
other concerns, or do you think the
On Fri, Aug 29, 2003 at 12:06:59AM -0300, Marc G. Fournier wrote:
tuning documents is *not* a valid reason for not doing this ... that's
like saying we can make it faster on some operating systems, but because
we're going to have to modify the tuning documents, we're not going to do
it ...
On Thu, 28 Aug 2003, David Schultz wrote:
(2) Make BLCKSZ a runtime constant, stored as part of the database.
Now this I really like. It would make benchmarking 8K vs. 16K blocksizes
much easer, as well as of course avoiding the initdb required after
rebuilding problem.
BTW, pretty much every
On Fri, Aug 29, 2003 at 12:06:59AM -0300, Marc G. Fournier wrote:
The thing is ... there has been presented a strong, valid reason for
moving to 16k (at least under FreeBSD) ... and there has been a valid
It sounds to me, actually, like there is a strong reason for telling
people running
This is a spill over from some discussions on some of the FreeBSD
mailing lists about FS performance. After FreeBSD 4.5-RELEASE, the
file system block size was bumped from 8K to 16K. Right now,
PostgreSQL still stores data in 8K blocks. Are there any objections
to me increasing the block size
Sean Chittenden [EMAIL PROTECTED] writes:
Are there any objections
to me increasing the block size for FreeBSD installations to 16K for
the upcoming 7.4 release?
I'm a little uncomfortable with introducing a cross-platform variation
in the standard block size. That would have implications for
Sean Chittenden [EMAIL PROTECTED] writes:
You do realize that you'll be forcing initdbs on people if you
blithely add and remove such a patch?
Yup. I was tempted to include another patch just to bump the catalog
version in the event that it doesn't gracefully detect differing block
sizes...
Thomas Swan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm a little uncomfortable with introducing a cross-platform variation
in the standard block size.
Has anyone looked at changing the default block size across the board
and what the performance improvements/penalties might be? Hardware
Are there any objections to me increasing the block size for
FreeBSD installations to 16K for the upcoming 7.4 release?
I'm a little uncomfortable with introducing a cross-platform
variation in the standard block size. That would have implications
for things like whether a table
Tom Lane wrote:
Sean Chittenden [EMAIL PROTECTED] writes:
Are there any objections
to me increasing the block size for FreeBSD installations to 16K for
the upcoming 7.4 release?
I'm a little uncomfortable with introducing a cross-platform variation
in the standard block size. That
Sean Chittenden [EMAIL PROTECTED] writes:
Hrm, well, given things just went to beta2, I'm going to bump
postgresql-devel to beta2 and include this patch for now, however, I'm
going to explicitly requests that people who have problems or
successes with beta2 on FreeBSD ask me before possible
Hrm, well, given things just went to beta2, I'm going to bump
postgresql-devel to beta2 and include this patch for now, however,
I'm going to explicitly requests that people who have problems or
successes with beta2 on FreeBSD ask me before possible reporting
problems with a platform
On Thu, 28 Aug 2003, Thomas Swan wrote:
Has anyone looked at changing the default block size across the board
and what the performance improvements/penalties might be? Hardware has
changed quite a bit over the years.
I *think* that the reason for the performance improvement on FreeBSD is
On Thu, Aug 28, 2003 at 03:56:18PM -0400, Tom Lane wrote:
Sean Chittenden [EMAIL PROTECTED] writes:
Hrm, well, given things just went to beta2, I'm going to bump
postgresql-devel to beta2 and include this patch for now, however, I'm
going to explicitly requests that people who have problems
Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm a little uncomfortable with introducing a cross-platform variation
in the standard block size.
Has anyone looked at changing the default block size across the board
and what the performance
On Thu, 28 Aug 2003, Marc G. Fournier wrote:
On Thu, 28 Aug 2003, Thomas Swan wrote:
Has anyone looked at changing the default block size across the board
and what the performance improvements/penalties might be? Hardware has
changed quite a bit over the years.
I *think* that the
Sean Chittenden [EMAIL PROTECTED] writes:
Early performance tests on my laptop suggest it's about 8% faster for
writing when both the FS and PostgreSQL use 16K blocks.
BTW, I don't really believe that one set of tests, conducted on one
single machine, are anywhere near enough justification for
20 matches
Mail list logo
