X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id B9C5C9DCAB1 for ; Mon, 5 Dec 2005 18:32:06 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 63575-10 for ; Mon, 5 Dec 2005 18:32:08 -0400 (AST) X-Greylist: delayed 00:59:50.170504 by SQLgrey- Received: from lobnya.ru (gw.lobnya.ru [213.171.58.250]) by postgresql.org (Postfix) with ESMTP id D9CDF9DCD30 for ; Mon, 5 Dec 2005 18:32:03 -0400 (AST) Received: from [10.0.14.9] ([10.0.14.9] verified) by lobnya.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 6318541; Tue, 06 Dec 2005 00:16:15 +0300 Message-ID: <4394B1D3.7000304@mail.ru> Date: Tue, 06 Dec 2005 00:32:03 +0300 From: Olleg Organization: Moscow Intitute of Physics and Technology User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane CC: pgsql-performance@postgresql.org Subject: Re: BLCKSZ References: <29518.1133794958@sss.pgh.pa.us> In-Reply-To: <29518.1133794958@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200512/135 X-Sequence-Number: 15956 Tom Lane wrote: > Olleg Samoylov 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