X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 0944DD9AC8; Wed, 28 Sep 2005 20:49:59 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 90012-01; Wed, 28 Sep 2005 23:49:54 +0000 (GMT) Received: from pop-gadwall.atl.sa.earthlink.net (pop-gadwall.atl.sa.earthlink.net [207.69.195.61]) by svr1.postgresql.org (Postfix) with ESMTP id 2CD81D9A84; Wed, 28 Sep 2005 20:49:55 -0300 (ADT) Received: from elwamui-polski.atl.sa.earthlink.net ([209.86.224.45]) by pop-gadwall.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EKlgV-0002ej-00; Wed, 28 Sep 2005 19:49:59 -0400 Message-ID: <16891246.1127951399015.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> Date: Wed, 28 Sep 2005 19:49:59 -0400 (EDT) From: Ron Peacetree Reply-To: Ron Peacetree To: pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org Subject: Re: [PERFORM] A Better External Sort? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.262 required=5 tests=[AWL=-0.112, DNS_FROM_RFC_ABUSE=0.374] X-Spam-Level: X-Archive-Number: 200509/1358 X-Sequence-Number: 73755 In the interest of efficiency and "not reinventing the wheel", does anyone know where I can find C or C++ source code for a Btree variant with the following properties: A= Data elements (RIDs) are only stored in the leaves, Keys (actually KeyPrefixes; see "D" below) and Node pointers are only stored in the internal nodes of the Btree. B= Element redistribution is done as an alternative to node splitting in overflow conditions during Inserts whenever possible. C= Variable length Keys are supported. D= Node buffering with a reasonable replacement policy is supported. E= Since we will know beforehand exactly how many RID's will be stored, we will know apriori how much space will be needed for leaves, and will know the worst case for how much space will be required for the Btree internal nodes as well. This implies that we may be able to use an array, rather than linked list, implementation of the Btree. Less pointer chasing at the expense of more CPU calculations, but that's a trade-off in the correct direction. Such source would be a big help in getting a prototype together. Thanks in advance for any pointers or source, Ron