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 9BADF9DC86B for ; Thu, 16 Feb 2006 19:05:14 -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 46083-07 for ; Thu, 16 Feb 2006 19:05:16 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from peufeu.com (unknown [82.67.9.10]) by postgresql.org (Postfix) with ESMTP id E83FF9DC83B for ; Thu, 16 Feb 2006 19:05:10 -0400 (AST) Received: (qmail 28176 invoked from network); 17 Feb 2006 00:05:24 +0100 Received: from unknown (HELO apollo13) (82.67.9.10) by boutiquenumerique.com with SMTP; 17 Feb 2006 00:05:24 +0100 Date: Fri, 17 Feb 2006 00:05:23 +0100 To: pgsql-performance@postgresql.org Subject: Re: [HACKERS] qsort again (was Re: Strange Create Index References: <43F38867.6010701@gpdnet.co.uk> <19510.1140036968@sss.pgh.pa.us> <19779.1140038874@sss.pgh.pa.us> <43F39E53.1020009@gpdnet.co.uk> <20781.1140046109@sss.pgh.pa.us> <7.0.1.0.2.20060215194635.03b55da0@earthlink.net> <21615.1140052893@sss.pgh.pa.us> <7.0.1.0.2.20060215223710.03a7c618@earthlink.net> <20060216113522.GA3461@uio.no> <7.0.1.0.2.20060216071053.0385a1a8@earthlink.net> <43F481CD.2010509@logix-tt.com> <43F4A7D8.4050907@modgraph-usa.com> <29277.1140110108@sss.pgh.pa.us> <1140128256.9076.254.camel@archimedes> From: PFC Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <1140128256.9076.254.camel@archimedes> User-Agent: Opera M2/8.51 (Linux, build 1462) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.093 required=5 tests=[AWL=0.093] X-Spam-Score: 0.093 X-Spam-Level: X-Archive-Number: 200602/267 X-Sequence-Number: 17253 > It seems that instead of maintaining a different sorting code path for > each data type, you could get away with one generic path and one > (hopefully faster) path if you allowed data types to optionally support > a 'sortKey' interface by providing a function f which maps inputs to 32- > bit int outputs, such that the following two properties hold: Looks like the decorate-sort-undecorate pattern, which works quite well. Good idea. I would have said a 64 bit int, but it's the same idea. However it won't work for floats, which is a pity, because floats fit in 64 bits. Unless more types creep in the code path (which would not necessarily make it that slower). As for text, the worst case is when all strings start with the same 8 letters, but a good case pops up when a few-letter code is used as a key in a table. Think about a zipcode, for instance. If a merge join needs to sort on zipcodes, it might as well sort on 64-bits integers... By the way, I'd like to declare my zipcode columns as SQL_ASCII while the rest of my database is in UNICODE, so they are faster to index and sort. Come on, MySQL does it... Keep up !