Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 30B1D633815 for ; Thu, 7 Jan 2010 23:31:56 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 31801-01-7 for ; Fri, 8 Jan 2010 03:31:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.postnewspapers.com.au (202-89-185-120.static.dsl.amnet.net.au [202.89.185.120]) by mail.postgresql.org (Postfix) with ESMTP id 2E303634002 for ; Thu, 7 Jan 2010 23:31:16 -0400 (AST) Received: from localhost (access [127.0.0.1]) by mail.postnewspapers.com.au (Postfix) with ESMTP id 0CA471E043B; Fri, 8 Jan 2010 11:31:13 +0800 (WST) X-Virus-Scanned: Debian amavisd-new at postnewspapers.com.au Received: from mail.postnewspapers.com.au ([127.0.0.1]) by localhost (access.postnewspapers.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oKkMfTNpf22h; Fri, 8 Jan 2010 11:31:11 +0800 (WST) Received: from [10.1.1.6] (124-169-133-89.dyn.iinet.net.au [124.169.133.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Craig Ringer", Issuer "POST Certificate Authority" (verified OK)) by mail.postnewspapers.com.au (Postfix) with ESMTPSA id B5B411E043A; Fri, 8 Jan 2010 11:31:10 +0800 (WST) Message-ID: <4B46A6FD.5070106@postnewspapers.com.au> Date: Fri, 08 Jan 2010 11:31:09 +0800 From: Craig Ringer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "Gurgel, Flavio" CC: Lefteris , pgsql-performance@postgresql.org, Ivan Voras Subject: Re: Air-traffic benchmark References: <32176465.41521262879116337.JavaMail.root@mail.4linux.com.br> In-Reply-To: <32176465.41521262879116337.JavaMail.root@mail.4linux.com.br> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.078 tagged_above=-10 required=5 tests=BAYES_05=-1.11, FH_DATE_PAST_20XX=3.188 X-Spam-Level: ** X-Archive-Number: 201001/133 X-Sequence-Number: 37013 On 7/01/2010 11:45 PM, Gurgel, Flavio wrote: >>> The table is very wide, which is probably why the tested databases >> can >>> deal with it faster than PG. You could try and narrow the table >> down >>> (for instance: remove the Div* fields) to make the data more >>> "relational-like". In real life, speedups in this circumstances >> would >>> probably be gained by normalizing the data to make the basic table >>> smaller and easier to use with indexing. > > Ugh. I don't think so. That's why indexes were invented. PostgreSQL is smart enough to "jump" over columns using byte offsets. Even if Pg tried to do so, it would generally not help. The cost of a disk seek to the start of the next row would be much greater than the cost of continuing to sequentially read until that point was reached. With the amazing sequential read speeds and still mediocre seek speeds modern disks it's rarely worth seeking over unwanted data that's less than a megabyte or two in size. Anyway, in practice the OS-level, array-level and/or disk-level readahead would generally ensure that the data you were trying to skip had already been read or was in the process of being read. Can Pg even read partial records ? I thought it all operated on a page level, where if an index indicates that a particular value is present on a page the whole page gets read in and all records on the page are checked for the value of interest. No? -- Craig Ringer