| From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
| Cc: | "Eric B(dot)Ridge" <ebr(at)tcdi(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Postgres + Xapian (was Re: fulltext searching via a |
| Date: | 2004-01-03 06:49:23 |
| Message-ID: | 3FF665F3.6090108@familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
> I think one way of attacking the problem would be using the existing
> nbtree by allowing it to store the five btrees. First read the README
> in the nbtree dir, and then poke at the metapage's only structure. You
> will see that it has a BlockNumber to the root page of the index. Try
> modifying that to make it have a BlockNumber to every index's root page.
> You will have to provide ways to access each root page and maybe other
> nonstandard things (such as telling the root split operation what root
> page are you going to split), but you will get recovery and concurrency
> (at least to a point) for free.
Why not write it using the GiST interface - that is after all the entire
point of GiST...
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gaetano Mendola | 2004-01-03 11:08:48 | Re: why the need for is null? |
| Previous Message | Tom Lane | 2004-01-03 05:31:10 | Re: Bug and/or feature? Complex data types in tables... |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ivan | 2004-01-03 08:25:14 | Re: time format |
| Previous Message | Tom Lane | 2004-01-03 05:31:10 | Re: Bug and/or feature? Complex data types in tables... |