Re: very large db performance question

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

In response to

Browse pgsql-performance by date

  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