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 awar
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 e
Jeff Davis <[EMAIL PROTECTED]> writes:
> $ ./cmp
> locale set to: en_US.UTF-8
> strcmp time elapsed: 2034183 us
> strcoll time elapsed: 2019880 us
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
comp
On Fri, 2007-05-04 at 13:52 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > I used strcmp() and strcoll() in a tight loop, and the result was
> > indistinguishable.
>
> That's not particularly credible ... were you testing this in a
> standalone test program? If so, did you re
Jeff Davis <[EMAIL PROTECTED]> writes:
> I used strcmp() and strcoll() in a tight loop, and the result was
> indistinguishable.
That's not particularly credible ... were you testing this in a
standalone test program? If so, did you remember to do setlocale()
first? Without that, you'll be in C l
On Thu, 2007-05-03 at 23:08 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > If you're using a non-C locale, it's slower than strcmp() too.
> > PostgreSQL has to do an extra memcpy() in order to use strcoll(),
> > because strings in postgresql aren't necessarily NULL-terminated a
On 5/3/07, Alexander Staubo <[EMAIL PROTECTED]> wrote:
PostgreSQL uses B-trees for its indexes, insertion time is logarithmic
regardless of the type of the key, but strings have a larger overhead
since they involve character comparisons; (i - j) is a lot faster than
strcmp(i, j). If you do go for
Jeff Davis <[EMAIL PROTECTED]> writes:
> If you're using a non-C locale, it's slower than strcmp() too.
> PostgreSQL has to do an extra memcpy() in order to use strcoll(),
> because strings in postgresql aren't necessarily NULL-terminated and
> there's no such thing as strncoll(), unfortunately (a
On Thu, 2007-05-03 at 22:32 +0200, Alexander Staubo wrote:
> On 5/3/07, Matthew Hixson <[EMAIL PROTECTED]> wrote:
> >Is there a significant performance difference between using int
> > primary keys and string primary keys in Postgres?
>
> PostgreSQL uses B-trees for its indexes, insertion time
On 5/3/07, Jeff Davis <[EMAIL PROTECTED]> wrote:
On Thu, 2007-05-03 at 08:58 -0700, Matthew Hixson wrote:
> I'm investigating the usage of a UUID primary key generator using
> Hibernate and Postgres. The reason for using a UUID is that we will
> have an application hosted at different sites in d
On 5/3/07, Matthew Hixson <[EMAIL PROTECTED]> wrote:
Is there a significant performance difference between using int
primary keys and string primary keys in Postgres?
PostgreSQL uses B-trees for its indexes, insertion time is logarithmic
regardless of the type of the key, but strings have a
On Thu, 2007-05-03 at 08:58 -0700, Matthew Hixson wrote:
> I'm investigating the usage of a UUID primary key generator using
> Hibernate and Postgres. The reason for using a UUID is that we will
> have an application hosted at different sites in different
> databases. We will need to aggreg
William Garrison wrote:
> I don't recommend it. There are better ways to store UUIDs:
>
> char(32)<-- Easy to work with, fixed length, inefficient
> varchar(32) <-- 4 bytes larger due to variable size
> bytea() <-- 20 bytes, variable length
> bit(128)<-- 16 bytes, optimal
>
> I don't
I don't recommend it. There are better ways to store UUIDs:
char(32)<-- Easy to work with, fixed length, inefficient
varchar(32) <-- 4 bytes larger due to variable size
bytea() <-- 20 bytes, variable length
bit(128)<-- 16 bytes, optimal
I don't like char() or varchar() because of ca
I'm investigating the usage of a UUID primary key generator using
Hibernate and Postgres. The reason for using a UUID is that we will
have an application hosted at different sites in different
databases. We will need to aggregate the data back into a single
database from time to time and
15 matches
Mail list logo
