Skip site navigation (1) Skip section navigation (2)

Re: CopyReadLineText optimization

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: CopyReadLineText optimization
Date: 2008-03-10 17:38:33
Message-ID: 47D57219.6080402@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches

Heikki Linnakangas wrote:
> Andrew Dunstan wrote:
>> Another question that occurred to me - did you try using strpbrk() to 
>> look for the next interesting character rather than your homegrown 
>> searcher gadget? If so, how did that perform?
>
> It looks like strpbrk() performs poorly:


Yes, not surprising. I just looked at the implementation in glibc, which 
I assume you are using, and it seemed rather basic. The one in NetBSD's 
libc looks much more efficient.

See

http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/libc/string/strpbrk.c?rev=1.1.2.1&content-type=text/plain&cvsroot=glibc
and
http://cvsweb.de.netbsd.org/cgi-bin/cvsweb.cgi/src/lib/libc/string/strpbrk.c?rev=1.16;content-type=text%2Fx-cvsweb-markup

Not that what you've done isn't good, if a little obscure (as is the 
NetBSD implementation)

cheers

andrew




In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2008-03-10 17:48:26
Subject: Re: Terminating a backend
Previous:From: Heikki LinnakangasDate: 2008-03-10 17:06:12
Subject: Re: [Fwd: Re: [PATCHES] 64-bit CommandIds]

pgsql-patches by date

Next:From: Bruce MomjianDate: 2008-03-10 17:48:26
Subject: Re: Terminating a backend
Previous:From: Rainer PruyDate: 2008-03-10 16:55:43
Subject: Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group