From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | LIANHE SHAO <lshao2(at)jhmi(dot)edu> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: very large db performance question |
Date: | 2003-11-27 01:03:14 |
Message-ID: | 3FC54D52.4040207@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> Thanks for reply. Actually our database only supply
> some scientists to use (we predict that). so there
> is no workload problem. there is only very
> infrequent updates. the query is not complex. the
> problem is, we have one table that store most of the
> data ( with 200 million rows). In this table, there
> is a text column which we need to do full text
> search for each row. The result will then join the
> data from another table which has 30,000 rows. Now
> the query runs almost forever.
Use TSearch2.
> I tried a small table with 2 million rows using the
> following simple command, it takes me about 6
> seconds to get the result back. So, I get confused.
> That is why I ask: Is it the hardware problem or
> something else. (I just vacuumed the whole database
> yesterday).
>
> PGA=> select count (*) from expressiondata ;
> count
> ---------
> 2197497
> (1 row)
select count(*) on a postgres table ALWAYS does a sequential scan. Just
don't do it. There are technical reasons (MVCC) why this is so. It's a
bad "test".
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Dror Matalon | 2003-11-27 01:03:52 | Re: For full text indexing, which is better, tsearch2 or |
Previous Message | Christopher Kings-Lynne | 2003-11-27 00:51:14 | Re: For full text indexing, which is better, tsearch2 or |