From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "James DeMichele" <James(dot)DeMichele(at)redfin(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Simple select, but takes long time |
Date: | 2008-01-12 02:11:18 |
Message-ID: | 29725.1200103878@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"James DeMichele" <James(dot)DeMichele(at)redfin(dot)com> writes:
> I am having a really hard time trying to figure out why my simple
> count(*) query is taking so long. I have a table with 1,296,070 rows in
> it. There are 2 different types of information that each row has that I
> care about:
Hmm, the EXPLAIN output works out to about 5 msec per row, which is not
too out of line for a lot of random-access disk fetches. I'm surprised
the planner bothered with an indexscan for this --- I'd bet a seqscan
might be faster, seeing you're having to read about 1% of the rows which
will likely touch most pages of the table anyway. Or a bitmap indexscan
might be even better. What do you get if you try the EXPLAIN ANALYZE
with enable_indexscan = off?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2008-01-12 02:56:38 | Re: Best way to index IP data? |
Previous Message | Michael Stone | 2008-01-12 01:58:47 | Re: Best way to index IP data? |