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-07 20:59:17
Message-ID: 47D1ACA5.80308@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches

Heikki Linnakangas wrote:
> Andrew Dunstan wrote:
>> I'm still a bit worried about applying it unless it gets some 
>> adaptive behaviour or something so that we don't cause any serious 
>> performance regressions in some cases.
>
> I'll try to come up with something. At the most conservative end, we 
> could fall back to the current method on the first escape, quote or 
> backslash character.
>
>> Also, could we perhaps benefit from inlining some calls, or is your 
>> compiler doing that anyway?
>
> gcc does inline all static functions that are only called from one 
> site,  and small functions, using some heuristic. I don't think more 
> aggressive inlining would help.
>

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?

cheers

andrew

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-03-07 21:20:01
Subject: Re: Re: [PATCHES] a tsearch2 (8.2.4) dictionary that only filters out stopwords
Previous:From: Andrew DunstanDate: 2008-03-07 20:53:48
Subject: Re: Commitfest process

pgsql-patches by date

Next:From: Tom LaneDate: 2008-03-07 21:20:01
Subject: Re: Re: [PATCHES] a tsearch2 (8.2.4) dictionary that only filters out stopwords
Previous:From: Bruce MomjianDate: 2008-03-07 20:22:20
Subject: Re: Cleaner API for appendStringInfoVA

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