Re: tsearch parser inefficiency if text includes urls or emails - new version

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Greg Smith" <greg(at)2ndquadrant(dot)com>
Cc: "Andres Freund" <andres(at)anarazel(dot)de>, <pgsql-hackers(at)postgresql(dot)org>,<oleg(at)sai(dot)msu(dot)su>, <teodor(at)sigaev(dot)ru>
Subject: Re: tsearch parser inefficiency if text includes urls or emails - new version
Date: 2009-12-07 15:32:15
Message-ID: 4B1CCB9F020000250002D10B@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Smith <greg(at)2ndquadrant(dot)com> wrote:

> After getting off to a good start, it looks like this patch is now
> stuck waiting for a second review pass from Kevin right now, with
> no open items for Andres to correct. Since the only issues on the
> table seem to be that of code aesthetics and long-term planning
> for this style of implementation rather than specific functional
> bits, I'm leaning toward saying this one is ready to have a
> committer look at it. Any comments from Kevin or Andres about
> where this is at?

Yeah, really the only thing I found to complain about was one
misspelled word in a comment. I am currently the hold-up, due to
fighting off a bout of some virus and having other "real world"
issues impinge. The only thing left to do, besides correcting the
spelling, is to confirm the author's performance improvements and
confirm that there is no degradation in a non-targeted situation.

Frankly, I'd be amazed if there was a performance regression,
because all it really does is pass a pointer to a new spot in an
existing input buffer rather than allocating new space and copying
the input from the desired spot to the end of the buffer. I can't
think of any situations where calculating the new address should be
slower than calculating the new address and copying from there to
the end of the buffer.

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-07 15:32:18 Re: How to cache a non-unique index?
Previous Message Tom Lane 2009-12-07 15:20:01 Re: YAML Was: CommitFest status/management