Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id C1F0D6326BC for ; Tue, 15 Jun 2010 03:10:22 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 01624-02 for ; Tue, 15 Jun 2010 06:10:15 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by mail.postgresql.org (Postfix) with SMTP id 9386463381A for ; Tue, 15 Jun 2010 03:10:14 -0300 (ADT) Received: from source ([74.125.82.47]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTBcZRVBGz4k9snojTCNgA/S/0BkyYElq@postini.com; Mon, 14 Jun 2010 23:10:14 PDT Received: by wwb17 with SMTP id 17so4625500wwb.6 for ; Mon, 14 Jun 2010 23:10:12 -0700 (PDT) Received: by 10.227.136.75 with SMTP id q11mr6914724wbt.26.1276582212648; Mon, 14 Jun 2010 23:10:12 -0700 (PDT) Received: from [192.168.1.117] (dsl-hkibrasgw2-ff7ac300-240.dhcp.inet.fi [88.195.122.240]) by mx.google.com with ESMTPS id y31sm43297217wby.10.2010.06.14.23.10.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jun 2010 23:10:12 -0700 (PDT) Message-ID: <4C171942.9060705@enterprisedb.com> Date: Tue, 15 Jun 2010 09:10:10 +0300 From: Heikki Linnakangas Organization: EnterpriseDB User-Agent: Mozilla/5.0 (X11; U; Linux i686; fi-FI; rv:1.9.1.9) Gecko/20100515 Iceowl/1.0b1 Icedove/3.0.4 MIME-Version: 1.0 To: Eliot Gable CC: pgsql-performance@postgresql.org Subject: Re: B-Heaps References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-4.2 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3 X-Spam-Level: X-Archive-Number: 201006/265 X-Sequence-Number: 39121 On 15/06/10 06:21, Eliot Gable wrote: > Just curious if this would apply to PostgreSQL: > http://queue.acm.org/detail.cfm?id=1814327 > > Now that I've read it, it seems > like a no-brainer. So, how does PostgreSQL deal with the different latencies > involved in accessing data on disk for searches / sorts vs. accessing data > in memory? Is it allocated in a similar way as described in the article such > that disk access is reduced to a minimum? I don't think we have any binary heap structures that are large enough for this to matter. We use a binary heap when merging tapes in the tuplesort code, for example, but that's tiny. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com