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 3893C9DD55C for ; Tue, 6 Dec 2005 06:40:52 -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 84321-07 for ; Tue, 6 Dec 2005 06:40:54 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from lobnya.ru (gw.lobnya.ru [213.171.58.250]) by postgresql.org (Postfix) with ESMTP id C872E9DD55B for ; Tue, 6 Dec 2005 06:40:49 -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 6349991; Tue, 06 Dec 2005 13:24:57 +0300 Message-ID: <43956AAF.7060108@mail.ru> Date: Tue, 06 Dec 2005 13:40:47 +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: Ron CC: pgsql-performance@postgresql.org Subject: Re: BLCKSZ References: <29518.1133794958@sss.pgh.pa.us> <4394B1D3.7000304@mail.ru> <6.2.5.6.0.20051205183120.01dd6a80@earthlink.net> In-Reply-To: <6.2.5.6.0.20051205183120.01dd6a80@earthlink.net> 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/156 X-Sequence-Number: 15977 Ron wrote: > In general, and in a very fuzzy sense, "bigger is better". pg files are > laid down in 1GB chunks, so there's probably one limitation. Hm, expect result of tests on other platforms, but if there theoretical dispute... I can't undestand why "bigger is better". For instance in search by index. Index point to page and I need load page to get one row. Thus I load 8kb from disk for every raw. And keep it then in cache. You recommend 64kb. With your recomendation I'll get 8 times more IO throughput, 8 time more head seek on disk, 8 time more memory cache (OS cache and postgresql) become busy. I have small row in often loaded table, 32 bytes. Table is not clustered, used several indices. And you recommend load 64Kb when I need only 32b, isn't it? -- Olleg