Re: [GENERAL] Creation of tsearch2 index is very - Mailing list pgsql-performance

From Ron
Subject Re: [GENERAL] Creation of tsearch2 index is very
Date
Msg-id 7.0.1.0.2.20060126202809.03838ab0@earthlink.net
Whole thread Raw
In response to Re: [GENERAL] Creation of tsearch2 index is very  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [GENERAL] Creation of tsearch2 index is very  ("Craig A. James" <cjames@modgraph-usa.com>)
List pgsql-performance
At 08:00 PM 1/26/2006, Alvaro Herrera wrote:
>Ron wrote:
> > At 01:27 PM 1/21/2006, Tom Lane wrote:
> > >Ron <rjpeace@earthlink.net> writes:
> > >> At 07:23 PM 1/20/2006, Tom Lane wrote:
> > >>> Well, we're trying to split an index page that's gotten full into
> > >>> two index pages, preferably with approximately equal numbers
> of items in
> > >>> each new page (this isn't a hard requirement though).
>
> > After reading the various papers available on GiST and RD trees, I
> > think I have a decent suggestion.
>
>I for one don't understand what does your suggestion have to do with the
>problem at hand ... not that I have a better one myself.

We have two problems here.
The first is that the page splitting code for these indexes currently
has O(N^2) performance.
The second is that whatever solution we do use for this
functionality, we still need good performance during searches that
use the index.  It's not clear that the solutions we've discussed to
splitting index pages thus far will result in good performance during searches.

My suggestion is intended to address both issues.

If I'm right it helps obtain high performance during searches while
allowing the index page splitting code to be O(1)

Ron.



pgsql-performance by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [GENERAL] Creation of tsearch2 index is very
Next
From: "Craig A. James"
Date:
Subject: Re: [GENERAL] Creation of tsearch2 index is very