Chris,
try REL8_1_STABLE branch, because you save a lot of time of indexing
Oleg
On Fri, 17 Mar 2006, Chris wrote:
Oleg Bartunov wrote:
On Wed, 15 Mar 2006, chris smith wrote:
Hi all,
Just wondering which full text module is better & what the differences
are between tsearch and fti ?
if
Oleg Bartunov wrote:
On Wed, 15 Mar 2006, chris smith wrote:
Hi all,
Just wondering which full text module is better & what the differences
are between tsearch and fti ?
if you need online indexing and linguistic support (dictionaries, stop
words, ranking) tsearch2 is fine. If your data are
On 3/15/06, chris smith <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Just wondering which full text module is better & what the differences
> are between tsearch and fti ?
Having only used tsearch/tsearch2 all I can say that it works as
advertised and I am extremely happy with it.
- Ian
On Wed, 15 Mar 2006, chris smith wrote:
Hi all,
Just wondering which full text module is better & what the differences
are between tsearch and fti ?
if you need online indexing and linguistic support (dictionaries, stop
words, ranking) tsearch2 is fine. If your data are static and you need
chris smith wrote:
Hi all,
Just wondering which full text module is better & what the differences
are between tsearch and fti ?
The table in question has roughly 80,000 rows.
I've been very happy with tsearch2. Note that if you're running an old
version of PostgreSQL (7.4?) there are some ma
Hi all,
Just wondering which full text module is better & what the differences
are between tsearch and fti ?
The table in question has roughly 80,000 rows.
Thanks!
--
Postgresql & php tutorials
http://www.designmagick.com/
---(end of broadcast)---
EXPLAIN
SELECT t1.id, t2.id
FROM test1 t1, test2 t2
WHERE lower( t1.keyword ) ~ ( lower ( '^' || t2.article ));
It doesn't appear that you're using tsearch2. PostgreSQL does not
include full text search in the basic installation. Have you installed
tsearch2?
Which is included in the Postgr
On Mar 1, 2006, at 6:54 , flood wrote:
Unfortunately I can not seem to get my query to use PG's full text
indexing, it keeps doing a seq scan:
EXPLAIN
SELECT t1.id, t2.id
FROM test1 t1, test2 t2
WHERE lower( t1.keyword ) ~ ( lower ( '^' || t2.article ));
It doesn't appear that you're usin
Hi folks, I am having some trouble with this query that should be using
FTI. There are 2 tables, one with a list of keywords and the other
containing a body of articles.
I am trying to get a query to return the IDs of each keyword with the
ID of each article that contains that keyword.
So the 2
Hello All,
I have installed Tsearch-Module for full text indexing .But when I search text
using gist(idxFTI) index on table I also found
all data which have same accent. Example
1.If I try search for MANI word it also search for MANY word.
2.If I try search for ANDY word it also search for ANDI
Mitch Vincent wrote:
>
> > Hi
> >
> > In my PostgreSQL database I have a lot of newspaper articles (size:
> > 100mb now, growing beyond 1gb within few months).
> > I wan't to use full text indexing so that users can search the articles
> > with a keyword and have the results in less than one seco
On Thu, 28 Sep 2000, Gilles DAROLD wrote:
> Hi,
>
> After taking a look to many way from fast search into full text (flat
> field with regrep, UDMSearch,
> and other stuff like contrib FTI) i have developped my own indexer and
> fast search.
> It's still specific to my database but can be easily
Hi,
After taking a look to many way from fast search into full text (flat
field with regrep, UDMSearch,
and other stuff like contrib FTI) i have developped my own indexer and
fast search.
It's still specific to my database but can be easily ported to any other
database structure.
It also use sto
On Tue, 18 Apr 2000, Bruce Momjian wrote:
> Let me be specific. The problem is that without cluster, your fragment
> rows are together in the index, but are all over the heap table, so you
> have to read in all those disk buffers, and that is slow. With cluster,
> most of your matching fragment
> On Tue, 18 Apr 2000, Bruce Momjian wrote:
>
> > > I agree! The last bit of advice given in the full text README. As I
> > > said, I'd built full-text stuff for experimentation (I had maybe 30k of
> > > raw text, which amounted to several 100,000 indexed entries), and I had
> > > clustered it,
> On Tue, 18 Apr 2000, Bruce Momjian wrote:
>
> > I have one word for you: CLUSTER. Without it, index lookups are too
> > slow. With it, they are rapid. I have done some work like this
> > commerically with Ingres, which has an ISAM type that keeps the matching
> > rows pretty close on a newl
On Tue, 18 Apr 2000, Bruce Momjian wrote:
> > I agree! The last bit of advice given in the full text README. As I
> > said, I'd built full-text stuff for experimentation (I had maybe 30k of
> > raw text, which amounted to several 100,000 indexed entries), and I had
> > clustered it, and it was
On Tue, 18 Apr 2000, Bruce Momjian wrote:
> I have one word for you: CLUSTER. Without it, index lookups are too
> slow. With it, they are rapid. I have done some work like this
> commerically with Ingres, which has an ISAM type that keeps the matching
> rows pretty close on a newly-created IS
> At 08:40 PM 18/04/00 -0400, Bruce Momjian wrote:
>
> >I have one word for you: CLUSTER. Without it, index lookups are too
> >slow. With it, they are rapid. I have done some work like this
> >commerically with Ingres, which has an ISAM type that keeps the matching
> >rows pretty close on a n
At 08:40 PM 18/04/00 -0400, Bruce Momjian wrote:
>I have one word for you: CLUSTER. Without it, index lookups are too
>slow. With it, they are rapid. I have done some work like this
>commerically with Ingres, which has an ISAM type that keeps the matching
>rows pretty close on a newly-created
> Does anyone have any experience using Postgres's full-text indexing in a
> production environment? We're thinking about using it for a project (the
> other solution is to regexp it with Perl...). I've set up the stuff
> before for experimentation, but am mainly curious about it's performance
>
21 matches
Mail list logo
