-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
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
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:
>
>ftp.postgresql.org:/pub/
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", tm->tm_w
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?
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
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
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
> > 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 u
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 accumArrayRes
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
> > 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
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 lon
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 t
> > > 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
> > > ~70
> > 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
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 fr
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 oppos
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 s
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]
20 matches
Mail list logo
