| 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: | Whole Thread | Raw Message | 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 |