From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ron Snyder <snyder(at)roguewave(dot)com> |
Cc: | pgsql General List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: How to track down inconsistent performance? |
Date: | 2002-04-28 14:58:52 |
Message-ID: | 20558.1020005932@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ron Snyder <snyder(at)roguewave(dot)com> writes:
> 'visible' is a boolean, 'product' is a varchar(30), and there are about 210K
> records in the builds table. (I don't know if it's relevant, but there are
> about 39 distinct product values.
Hmm, a rough guess would suggest that the query will be retrieving about
1/78th of the rows (unless there are statistics you haven't mentioned that
affect that). I would think that a seqscan would be faster for this.
I would definitely think that the planner would think so --- are you
forcing enable_seqscan off?
Since you're evidently running 7.2, I'd ask for EXPLAIN ANALYZE rather
than just EXPLAIN output. It'd be even more helpful if you are able
to catch both the fast and slow cases under EXPLAIN ANALYZE.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | dorian dorian | 2002-04-28 15:44:44 | Re: icps, shmmax and shmall - Shared Memory tuning |
Previous Message | Tom Lane | 2002-04-28 14:49:38 | Re: Compiling 7.2 on Solaris 8: runtime error on libssl.so.0.9.6 |