There's been work on it. Theodor cleaned it up for HEAD and looked at
adding GiST support. I beleive he's waiting for 8.2 to release.
Yep, I have bundle of patches and I'm waiting for 8.2 branch split out of HEAD.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
I'm playing with GIN to make a full text search system. GIN comes with
built-in TEXT[] support and I use string_to_array() to make a
TEXT[]. Problem is, if there's large number of array elemets,
string_to_array() consumes too much memory. For example, to make ~70k
array elements, string_to_array
Richard Whidden wrote:
Due to popular demand (1 person), I've compared sizes with 90 and 100
fillfactors, along with using the new GIN index.
First, GIN doesn't utilize fillfactor option yet.
Findings were not surprising, except for the GIN indexes, which doubled
in size.
Second, In
Andrew Dunstan wrote:
Marc G. Fournier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As a result of there being two *known* outstanding bugs, we have just
bundled up a Beta3, to allow for testing of the recent patch
concerning WAL replay ...
What are the bugs?
AFAIK:
1. Tuple
I'm playing with GIN to make a full text search system. GIN comes with
built-in TEXT[] support and I use string_to_array() to make a
TEXT[]. Problem is, if there's large number of array elemets,
string_to_array() consumes too much memory. For example, to make ~70k
array elements,
I'm playing with GIN to make a full text search system. GIN comes
with built-in TEXT[] support and I use string_to_array()
to make a
TEXT[]. Problem is, if there's large number of array elemets,
string_to_array() consumes too much memory. For example, to make
~70k array
I'm testing how GIN scales.
Have a look at http://www.sigaev.ru/cvsweb/cvsweb.cgi/ftsbench/ - utility is
specially developed for measuring performance of full-text solutions ( now it
supports PgSQL( GiST, GIN ) and MySQL ). Right now I'm searching good query
statistic for simulate load, but
On Tue, Nov 07, 2006 at 07:11:35PM -0600, Bruno Wolff III wrote:
On Sun, Nov 05, 2006 at 11:49:36 -0500,
Tom Lane [EMAIL PROTECTED] wrote:
As already discussed upthread, anyone who wants the path can get it from
`pwd` or local equivalent --- and that mechanism is robust (as long as
I'm testing how GIN scales.
Have a look at http://www.sigaev.ru/cvsweb/cvsweb.cgi/ftsbench/ - utility is
specially developed for measuring performance of full-text solutions ( now it
supports PgSQL( GiST, GIN ) and MySQL ). Right now I'm searching good query
statistic for simulate load,
Porblem with Japanese is, it's an agglutinative language and we need
to separate each word from a sentence. So, I need to modify tsearch2
anyway (I know someone from Japan is working on this).
https://www.oss.ecl.ntt.co.jp/tsearch2j/index.html
That's it?
BTW, can tsearch2 handle ~70k words in
Tatsuo Ishii [EMAIL PROTECTED] writes:
string_to_array() consumes too much memory. For example, to make ~70k
array elements, string_to_array seems to eat several Gig bytes of
memory.
I'd argue that the problem comes from enlarging the work arrays only 64
elements at a time in
Porblem with Japanese is, it's an agglutinative language and we need
to separate each word from a sentence. So, I need to modify tsearch2
anyway (I know someone from Japan is working on this).
https://www.oss.ecl.ntt.co.jp/tsearch2j/index.html
That's it?
Yes. However I'm going to use
tsvector size should not be greater than 1Mb however.
Is this documented somewhere? Also I noticed that tsearch2 treats :
as a special character. Are there any special characters? If so where
are they documented?
http://www.sai.msu.su/~megera/wiki/Tsearch_V2_in_Brief
Limitations
13.1
Is this documented somewhere? Also I noticed that tsearch2 treats :
as a special character. Are there any special characters? If so where
are they documented?
You can avoid confusions with special character by quoting:
# select '''wow:'''::tsvector;
tsvector
--
'wow:'
(1 row)
':' is
Limitations
Sorry for noise - it's mentioned in README.tsearch2
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of broadcast)---
TIP
On Thu, 9 Nov 2006, Tatsuo Ishii wrote:
Porblem with Japanese is, it's an agglutinative language and we need
to separate each word from a sentence. So, I need to modify tsearch2
anyway (I know someone from Japan is working on this).
https://www.oss.ecl.ntt.co.jp/tsearch2j/index.html
That's it?
Hey hackers,
I was doing some work in backend/utils/adt/formatting.c, and found the
following:
case DCH_D:
INVALID_FOR_INTERVAL;
if (is_to_char)
{
sprintf(inout, %d,
On Tuesday 07 November 2006 13:25, Marc G. Fournier wrote:
As a result of there being two *known* outstanding bugs, we have just
bundled up a Beta3, to allow for testing of the recent patch concerning WAL
replay ...
Please download the latest beta from:
On Monday 06 November 2006 20:16, Jim C. Nasby wrote:
On Sun, Nov 05, 2006 at 09:53:08PM +0100, Martijn van Oosterhout wrote:
Note that the constructs:
ARRAY['a',NULL,'c']
and
'{a,NULL,c}'
are *completely* different. The first is a special array constructor
and all its
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Done ...
- --On Wednesday, November 08, 2006 21:31:38 -0500 Robert Treat
[EMAIL PROTECTED] wrote:
On Tuesday 07 November 2006 13:25, Marc G. Fournier wrote:
As a result of there being two *known* outstanding bugs, we have just
bundled up a
20 matches
Mail list logo
