From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Alexander Staubo <alex(at)purefiction(dot)net>, Matthew Hixson <hixson(at)poindextrose(dot)org>, Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: varchar as primary key |
Date: | 2007-05-04 21:45:56 |
Message-ID: | 20070504214556.GC28680@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, May 04, 2007 at 03:42:45PM -0400, Tom Lane wrote:
> It's hardly credible that you could do either strcmp or strcoll in 2 nsec
> on any run-of-the-mill hardware. What I think is happening is that the
> compiler is aware that these are side-effect-free functions and is
> removing the calls entirely, or at least moving them out of the loops;
> these times would be credible for loops consisting only of an increment,
> test, and branch.
It's not the compiler, it's the C library. strcmp and strcoll are
defined as:
extern int strcoll (__const char *__s1, __const char *__s2)
__THROW __attribute_pure__ __nonnull ((1, 2));
In this context "pure" is essentially what IMMUTABLE is in postgres.
Which doesn't change the fact that strcoll is expensive.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-04 21:49:13 | Re: Casting to varchar |
Previous Message | Michael Glaesemann | 2007-05-04 21:30:18 | Re: Casting to varchar |