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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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