Oleg Bartunov wrote:
stat() is indeed a bigdog, it was designed for developers needs,
so we recommend to save results in table.
Anyway, here's my pg_ts_cfgmap now (well the relevant bits):
default_english | lhword | {en_ispell,en_stem}
default_english | lpart_hword | {en_ispell,en_stem}
defa
On Thu, 24 Mar 2005, Rick Jansen wrote:
Oleg Bartunov wrote:
from my notes
http://www.sai.msu.su/~megera/oddmuse/index.cgi/Tsearch_V2_Notes
It's usefull to see words statistics, for example, to check how good
your dictionaries work or how did you configure pg_ts_cfgmap. Also, you
may notice probabl
Oleg Bartunov wrote:
> from my notes
> http://www.sai.msu.su/~megera/oddmuse/index.cgi/Tsearch_V2_Notes
>
> It's usefull to see words statistics, for example, to check how good
> your dictionaries work or how did you configure pg_ts_cfgmap. Also, you
> may notice probable stop words relevant for yo
On Wed, 23 Mar 2005, Rick Jansen wrote:
Oleg Bartunov wrote:
On Tue, 22 Mar 2005, Rick Jansen wrote:
Hmm, default configuration is too eager, you index every lexem using simple
dictionary) ! Probably, it's too much. Here is what I have for my russian
configuration in dictionary database:
defaul
Oleg Bartunov wrote:
On Tue, 22 Mar 2005, Rick Jansen wrote:
Hmm, default configuration is too eager, you index every lexem using
simple dictionary) ! Probably, it's too much. Here is what I have for my
russian configuration in dictionary database:
default_russian | lword| {en_ispell,en
On Tue, 22 Mar 2005, Rick Jansen wrote:
Oleg Bartunov wrote:
Mike,
no comments before Rick post tsearch configs and increased buffers !
Union shouldn't be faster than (term1|term2).
tsearch2 internals description might help you understanding tsearch2
limitations.
See http://www.sai.msu.su/~megera
Oleg Bartunov wrote:
Mike,
no comments before Rick post tsearch configs and increased buffers !
Union shouldn't be faster than (term1|term2).
tsearch2 internals description might help you understanding tsearch2
limitations.
See http://www.sai.msu.su/~megera/oddmuse/index.cgi/Tsearch_V2_internals
Mike,
no comments before Rick post tsearch configs and increased buffers !
Union shouldn't be faster than (term1|term2).
tsearch2 internals description might help you understanding tsearch2
limitations.
See http://www.sai.msu.su/~megera/oddmuse/index.cgi/Tsearch_V2_internals
Also, don't miss my n
On Tue, 22 Mar 2005 14:25:19 +0100, Rick Jansen <[EMAIL PROTECTED]> wrote:
>
> ilab=# explain analyze select count(titel) from books where idxfti @@
> to_tsquery('default', 'buckingham | palace');
> QUERY PLAN
> --
Mike Rylander wrote:
On Tue, 22 Mar 2005 15:36:11 +0300 (MSK), Oleg Bartunov wrote:
use something like
echo "15000" > /proc/sys/kernel/shmmax
to increase shared memory. In your case you could dedicate much more
memory.
Regards,
Oleg
Thanks, I'll check that out.
And Oleg
On Tue, 22 Mar 2005, Mike Rylander wrote:
And Oleg should know. Unless I'm mistaken, he (co)wrote tsearch2.
You're not mistaken :)
Other than shared buffers, I can't imagine what could be causing that
kind of slowness. EXPLAIN ANALYZE, please?
tsearch2 config's also are very important. I've seen
On Tue, 22 Mar 2005 15:36:11 +0300 (MSK), Oleg Bartunov wrote:
> On Tue, 22 Mar 2005, Rick Jansen wrote:
>
> > Hi,
> >
> > I'm looking for a *fast* solution to search thru ~ 4 million records of book
> > descriptions. I've installed PostgreSQL 8.0.1 on a dual opteron server with
> > 8G of memory,
On Tue, 22 Mar 2005, Rick Jansen wrote:
Hi,
I'm looking for a *fast* solution to search thru ~ 4 million records of book
descriptions. I've installed PostgreSQL 8.0.1 on a dual opteron server with
8G of memory, running Linux 2.6. I haven't done a lot of tuning on PostgreSQL
itself, but here's th
13 matches
Mail list logo
