"Scott Marlowe" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
