Re: tsearch in core patch, for inclusion - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: tsearch in core patch, for inclusion
Date
Msg-id 200702211401.l1LE1px27523@momjian.us
Whole thread Raw
In response to Re: tsearch in core patch, for inclusion  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Oleg Bartunov wrote:
> >> It's not so big addition to the gram.y, see a list of commands
> >> http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
> 
> > I looked at the diff file and the major change in gram.y is the creation
> > of a new object type FULLTEXT,
> 
> You mean four different object types.  I'm not totally clear on bison's
> scaling behavior relative to the number of productions, but I think
> there's no question that this patch will impose a measurable distributed
> penalty on every single query issued to Postgres by any application,
> whether it's heard of tsearch or not.  The percentage overhead would
> be a lot lower if the patch were introducing a similar number of entries
> into pg_proc.

My point is that the grammar splits off all the tsearch2 objects by
prefixing them with CREATE FULLTEXT object, where there are four object
types supported.

But as others have pointed out, the performance of the grammar is
probably not an issue in this case.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: --enable-xml instead of --with-libxml?
Next
From: Alvaro Herrera
Date:
Subject: Re: New feature request: FlashBack Query