X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 5E3419DC810; Fri, 17 Feb 2006 13:30:46 -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 79497-10; Fri, 17 Feb 2006 13:30:45 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from mir3-fs.mir3.com (mail.mir3.com [65.208.188.100]) by postgresql.org (Postfix) with ESMTP id 732169DCA31; Fri, 17 Feb 2006 13:30:42 -0400 (AST) Received: mir3-fs.mir3.com 172.16.1.11 from 172.16.2.68 172.16.2.68 via HTTP with MS-WebStorage 6.0.6249 Received: from archimedes.mirlogic.com by mir3-fs.mir3.com; 17 Feb 2006 09:30:37 -0800 Subject: Re: qsort again (was Re: [PERFORM] Strange Create Index From: Mark Lewis To: David Lang Cc: Greg Stark , Markus Schaber , pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org In-Reply-To: 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> <43F4FDCC.2000204@logix-tt.com> <871wy23okp.fsf@stark.xeocode.com> <1140132189.9076.261.camel@archimedes> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: MIR3, Inc. Date: Fri, 17 Feb 2006 09:30:37 -0800 Message-Id: <1140197437.9076.268.camel@archimedes> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.131 required=5 tests=[AWL=0.130, UNPARSEABLE_RELAY=0.001] X-Spam-Score: 0.131 X-Spam-Level: X-Archive-Number: 200602/668 X-Sequence-Number: 79806 On Thu, 2006-02-16 at 21:33 -0800, David Lang wrote: > > In SQL_ASCII, just take the first 4 characters (or 8, if using a 64-bit > > sortKey as elsewhere suggested). The sorting key doesn't need to be a > > one-to-one mapping. > > that would violate your second contraint ( f(a)==f(b) iff (a==b) ) > > if you could drop that constraint (the cost of which would be extra 'real' > compares within a bucket) then a helper function per datatype could work > as you are talking. I think we're actually on the same page here; you're right that the constraint above ( f(a)==f(b) iff a==b ) can't be extended to data types with more than 32 bits of value space. But the constraint I listed was actually: if a==b then f(a)==f(b) Which doesn't imply 'if and only if'. It's a similar constraint to hashcodes; the same value will always have the same hash, but you're not guaranteed that the hashcodes for two distinct values will be unique. -- Mark