Bruce Momjian wrote:
>
> > On Tue, 16 May 2000, Bruce Momjian wrote:
> >
> > > > On Tue, 16 May 2000, Michael A. Olson wrote:
> > > >
> > > > > Rather than replacing just the storage manager, you'd be replacing
> > > > > the access methods, buffer manager, transaction manager, and some
> > > > > of the shared memory plumbing with our stuff.
> > > >
> > > > So, basically, we rip out 3+ years or work on our backend and put an SQL
> > > > front-end over top of BerkleyDB?
> > >
> > > Now, no one is suggesting we do this. The issue is exploring what gains
> > > we could make in doing this.
> >
> > Definitely ... I'm just reducing it down to simpler terms, that's all :)
>
> I am glad you did. I like the fact we are open to re-evaluate our code
> and consider code from outside sources. Many open-source efforts have
> problems with code-not-made-here.
I have been planning to add a full-text index (a.k.a. inverted index) to
postgres
text and array types for some time already. This is the only major index
type
not yet supported by postgres and currently implemented as an external
index in
our products. I have had a good excuse (for me) for postponing that work
in
the limited size of text datatype (actually the tuples) but AFAIK it is
going
away in 7.1 ;)
I have done a full-text index for a major national newspaper that has
worked
ok for several years using python and old (v1.86, pre-sleepycat) BSD DB
code - I
stayed away from 2.x versions due to SC license terms. I'm happy to
hear that BSD DB and postgreSQL storage schemes are designed to be
compatible.
But I still suspect that taking some existing postgres index (most
likely btree)
as base would be less effort than integrating locking/transactions of
PG/BDB.
------------
Hannu
