| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | "Scott Marlowe" <smarlowe(at)qwest(dot)net> |
| Cc: | "Jack Kerkhof" <jack(dot)kerkhof(at)guest-tek(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Why does a simple query not use an obvious index? |
| Date: | 2004-08-29 21:12:05 |
| Message-ID: | 87fz65k5sq.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Scott Marlowe" <smarlowe(at)qwest(dot)net> writes:
> Also, count(*) is likely to always generate a seq scan due to the way
> aggregates are implemented currently in pgsql. you might want to try:
Huh? I'm curious to know what you're talking about here.
> select somefield from sometable where timestampfield > now()-'60
> seconds'::interval
>
> and count the number of returned rows. If there's a lot, it won't be
> any faster, if there's a few, it should be a win.
Why would this ever be faster? And how could postgres ever calculate that
without doing a sequential scan when count(*) would force it to do a
sequential scan?
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2004-08-29 21:38:00 | Re: Why does a simple query not use an obvious index? |
| Previous Message | Greg Stark | 2004-08-29 21:10:37 | Re: Why does a simple query not use an obvious index? |