From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: tsearch in core patch, for inclusion |
Date: | 2007-02-21 05:49:11 |
Message-ID: | 7164.1172036951@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian <bruce(at)momjian(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Csaba Nagy | 2007-02-21 09:17:37 | Re: New feature request: FlashBack Query |
Previous Message | Greg Smith | 2007-02-21 03:59:37 | Re: WIP patch - INSERT-able log statements |
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schiltknecht | 2007-02-21 11:04:47 | Re: tsearch in core patch, for inclusion |
Previous Message | Greg Smith | 2007-02-21 03:59:37 | Re: WIP patch - INSERT-able log statements |