Re: varchar as primary key

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

In response to

Browse pgsql-general by date

  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