| From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
| Cc: | "C(dot) Filipe Medeiros" <filipe(at)mercenary3(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-advocacy(at)postgresql(dot)org |
| Subject: | Re: First Step to Major Use: Integrated Full-Text |
| Date: | 2005-12-06 01:49:58 |
| Message-ID: | 4394EE46.6030901@familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-advocacy |
>> Although I agree with your arguments for integration, I should point
>> out that MySQL's full text indexing and it's transactions are mutually
>> exclusive. You can't have both.
>
> E.g; if you are using full text with MySQL, you are using a bum backend
> destined to loose data.
One of the new things going on in MySQL is this new demo db they're
doing called 'Sakila' (I've ported it to PgSQL, just waiting for license
details).
In it they "solve" the problem by having - wonder of wonders - a
trigger! It's meant as an example of how the new trigger/stored proc
features of MySQL 5 can maintain a non-transactional full text index
table, and have the main table transactional.
I then asked what happens when the transaction that causes the trigger
to trigger gets rolled back - in that case the FTI table is not rolled
back, so the index is quite out of date. I thought that was funny :D
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marc G. Fournier | 2005-12-06 02:16:47 | Re: First Step to Major Use: Integrated Full-Text |
| Previous Message | C. Filipe Medeiros | 2005-12-06 01:41:44 | Re: First Step to Major Use: Integrated Full-Text |