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 6115C9DC973;
	Thu, 16 Feb 2006 18:40:34 -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 34457-06; Thu, 16 Feb 2006 18:40:35 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from svana.org (svana.org [125.62.94.225])
	by postgresql.org (Postfix) with ESMTP id 7C8C29DC86B;
	Thu, 16 Feb 2006 18:40:31 -0400 (AST)
Received: from kleptog by svana.org with local (Exim 4.50)
	id 1F9rnC-0000jI-9z; Fri, 17 Feb 2006 09:40:06 +1100
Date: Thu, 16 Feb 2006 23:40:06 +0100
From: Martijn van Oosterhout <kleptog@svana.org>
To: Mark Lewis <mark.lewis@mir3.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "Craig A. James" <cjames@modgraph-usa.com>,
	Markus Schaber <schabi@logix-tt.com>,
	pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: qsort again (was Re: [PERFORM] Strange Create Index
Message-ID: <20060216224006.GK26127@svana.org>
Reply-To: Martijn van Oosterhout <kleptog@svana.org>
References: <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>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="P7Tqkd/m/Jnohiaz"
Content-Disposition: inline
In-Reply-To: <1140128256.9076.254.camel@archimedes>
X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6
X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522  48A7 6394 F08A 0DC6 7BE6
X-PGP-Key-URL: <http://svana.org/kleptog/0DC67BE6.pgp.asc>
User-Agent: Mutt/1.5.9i
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: kleptog@svana.org
X-SA-Exim-Scanned: No (on svana.org); SAEximRunCond expanded to false
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.123 required=5 tests=[AWL=0.123]
X-Spam-Score: 0.123
X-Spam-Level: 
X-Archive-Number: 200602/644
X-Sequence-Number: 79782


--P7Tqkd/m/Jnohiaz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 16, 2006 at 02:17:36PM -0800, Mark Lewis wrote:
> 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:
>=20
> f(a)>=3Df(b) iff a>=3Db
> if a=3D=3Db then f(a)=3D=3Df(b)

Note this is a property of the collation, not the type. For example
strings can be sorted in many ways and the sortKey must reflect that.
So in postgres terms it's a property of the btree operator class.

It's something I'd like to do if I get A Round Tuit. :)

Have a nice day,
--=20
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

--P7Tqkd/m/Jnohiaz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD9P9GIB7bNG8LQkwRAtB9AJwKlPgpniwDtbKSxJNNeNoPuXzU5gCdFYsD
diX9/Sk6Ua49glk4VApgnIw=
=IwiP
-----END PGP SIGNATURE-----

--P7Tqkd/m/Jnohiaz--