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

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: tsearch parser inefficiency if text includes urls or emails - new version
Дата
Msg-id 4B1CCB9F020000250002D10B@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: tsearch parser inefficiency if text includes urls or emails - new version  (Greg Smith <greg@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: YAML Was: CommitFest status/management
Следующее
От: Tom Lane
Дата:
Сообщение: Re: How to cache a non-unique index?