From: | Mark Lewis <mark(dot)lewis(at)mir3(dot)com> |
---|---|
To: | David Lang <dlang(at)invendra(dot)net> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Markus Schaber <schabi(at)logix-tt(dot)com>, pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: qsort again (was Re: [PERFORM] Strange Create Index |
Date: | 2006-02-17 17:30:37 |
Message-ID: | 1140197437.9076.268.camel@archimedes |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Ragnar | 2006-02-17 19:22:49 | Re: qsort again (was Re: [PERFORM] Strange Create |
Previous Message | Michael Paesold | 2006-02-17 17:09:52 | Re: Need pointers to "standard" pg database(s) for testing |
From | Date | Subject | |
---|---|---|---|
Next Message | Ragnar | 2006-02-17 19:22:49 | Re: qsort again (was Re: [PERFORM] Strange Create |
Previous Message | Michael Paesold | 2006-02-17 17:09:52 | Re: Need pointers to "standard" pg database(s) for testing |