| From: | Joshua Tolley <eggyknap(at)gmail(dot)com> |
|---|---|
| To: | Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com> |
| Cc: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Neil Whelchel <neil(dot)whelchel(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Slow count(*) again... |
| Date: | 2010-10-11 03:21:54 |
| Message-ID: | 4cb282d7.2405720a.5ca5.fffff05b@mx.google.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On Sun, Oct 10, 2010 at 11:14:43PM -0400, Mladen Gogala wrote:
> The fact is, however, that the question
> about slow sequential scan appears with some regularity on PostgreSQL
> forums.
Definitely. Whether that's because there's something pathologically wrong with
sequential scans, or just because they're the slowest of the common
operations, remains to be seen. After all, if sequential scans were suddenly
fast, something else would be the slowest thing postgres commonly did.
All that said, if there's gain to be had by increasing block size, or
something else, esp. if it's low hanging fruit, w00t.
--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2010-10-11 04:11:58 | Re: Slow count(*) again... |
| Previous Message | Mladen Gogala | 2010-10-11 03:14:43 | Re: Slow count(*) again... |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2010-10-11 04:11:58 | Re: Slow count(*) again... |
| Previous Message | Mladen Gogala | 2010-10-11 03:14:43 | Re: Slow count(*) again... |