Re: tsearch parser inefficiency if text includes urls or emails - new version - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: tsearch parser inefficiency if text includes urls or emails - new version
Date
Msg-id 4B1CCB9F020000250002D10B@gw.wicourts.gov
Whole thread Raw
In response to Re: tsearch parser inefficiency if text includes urls or emails - new version  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-hackers
Greg Smith <greg@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: YAML Was: CommitFest status/management
Next
From: Tom Lane
Date:
Subject: Re: How to cache a non-unique index?