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
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 Free
I am not 100% sure that 16K blocksize is the best size, for instance :
Using FreebSD 5.1 - I got the best read and write performance using a
blocksize of 32K with 4K fragments - [ reading and writing 8K blocks,
ufs1 and ufs2 fs ].
I dont have the results in front of me, but I think I tried fs
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 ever
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, 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 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 cas
> > > 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 thi
On Thu, Aug 28, 2003, 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 th
On Thu, Aug 28, 2003, scott.marlowe wrote:
> 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
> > >
Sean, can we get a copy of your test set? And any scripts that you have
for running the tests?
On Thu, 28 Aug 2003, Tom Lane wrote:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > Early performance tests on my laptop suggest it's about 8% faster for
> > writing when both the FS and PostgreSQ
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 f
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 *thin
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 t
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
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
> > 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 pla
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 possib
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 bloc
> > 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 d
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?
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
>
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
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 fo
24 matches
Mail list logo
