From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:54:17 |
Message-ID: | 1178315657.12793.43.camel@dogma.v10.wvs |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 2007-05-04 at 23:45 +0200, Martijn van Oosterhout wrote:
> 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.
>
Thanks for clearing that up. I should have done a sanity check on those
numbers to begin with.
By the way, I didn't see the warning Tom mentioned using -Wall on either
system.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2007-05-05 01:07:53 | Re: Feature Request --- was: PostgreSQL Performance Tuning |
Previous Message | Tom Lane | 2007-05-04 21:49:13 | Re: Casting to varchar |