From: | Olleg <olleg_s(at)mail(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: BLCKSZ |
Date: | 2005-12-05 21:32:03 |
Message-ID: | 4394B1D3.7000304@mail.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane wrote:
> Olleg Samoylov <olleg_s(at)mail(dot)ru> writes:
>
>>I try to test this. Linux, memory page 4kb, disk page 4kb. I set BLCKSZ
>>to 4kb. I get some performance improve, but not big, may be because I
>>have 4Gb on test server (amd64).
>
> It's highly unlikely that reducing BLCKSZ is a good idea. There are bad
> side-effects on the maximum index entry size, maximum number of tuple
> fields, etc.
Yes, when I set BLCKSZ=512, database dont' work. With BLCKSZ=1024
database very slow. (This was surprise me. I expect increase performance
in 8 times with 1024 BLCKSZ. :) ) As I already see in this maillist,
increase of BLCKSZ reduce performace too. May be exist optimum value?
Theoretically BLCKSZ equal memory/disk page/block size may reduce
defragmentation drawback of memory and disk.
> In any case, when you didn't say *what* you tested, it's
> impossible to judge the usefulness of the change.
> regards, tom lane
I test performace on database test server. This is copy of working
billing system to test new features and experiments. Test task was one
day traffic log. Average time of a one test was 260 minutes. Postgresql
7.4.8. Server dual Opteron 240, 4Gb RAM.
--
Olleg
From | Date | Subject | |
---|---|---|---|
Next Message | rm_pg | 2005-12-05 22:13:02 | Missed index opportunity for outer join? |
Previous Message | Bruno Wolff III | 2005-12-05 20:36:04 | Re: Performance degradation after successive UPDATE's |