"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?


---------------------------(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

Reply via email to