| From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
|---|---|
| To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
| Cc: | Hannes Dorbath <light(at)theendofthetunnel(dot)de>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: TSearch2 Questions |
| Date: | 2005-11-21 17:24:35 |
| Message-ID: | 20051121172435.GA21245@wolff.to |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Nov 21, 2005 at 16:50:00 +0300,
Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> wrote:
> On Mon, 21 Nov 2005, Hannes Dorbath wrote:
>
> >I'm playing a bit with it ATM. Indexing one Gigabyte of plain text worked
> >well, with 10 GB I yet have some performance problems. I read the TSearch
> >Tuning Guide and will start optimizing some things, but is it a realistic
> >goal to index ~90GB plain text and get sub-second response times on
> >hardware that ~4000 EUR can buy?
>
> What's ATM ? As for the sub-second response times it'd very depend on
> your data and queries. It'd be certainly possible with our tsearch daemon
> which we postponed, because we inclined to implement inverted indices first
> and then build fts index on top of inverted index. But this is long-term
> plan.
I believe in this context, 'ATM' is an ancronym for 'at the moment' which
has little impact on the meaning of the paragraph.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Berend Tober | 2005-11-21 17:33:15 | Re: Multi-parameter aggregates. |
| Previous Message | Tom Lane | 2005-11-21 17:06:40 | Re: Multi-parameter aggregates. |