Kashmira Patel wrote:
> I did do an EXPLAIN ANALYZE as well, it also showed a
> sequential scan. The table has about 600+ rows, with around 6 of them
> matching the given id. Wouldn't an index scan be faster in this case?
Not necessarily. It's entirely possible, if your rows are small, that 600
Sent: Thursday, February 23, 2006 2:47 PM
To: pgsql-sql@postgresql.org
Subject: Re: [SQL] Question about index scan vs seq scan when using
count()
On Thu, Feb 23, 2006 at 02:25:34PM -0800, Kashmira Patel (kupatel)
wrote:
>
> [Kashmira] I did do an EXPLAIN ANALYZE as well, it also sh
On Thu, Feb 23, 2006 at 02:25:34PM -0800, Kashmira Patel (kupatel) wrote:
>
> [Kashmira] I did do an EXPLAIN ANALYZE as well, it also showed a
> sequential scan. The table has about 600+ rows, with around 6 of them
> matching the given id. Wouldn't an index scan be faster in this case?
EXPLAIN AN
: [SQL] Question about index scan vs seq scan when using
count()
> What am I doing wrong here? I want it to use my index.
For small tables the sequential scan is faster, that means less disk
reads is required the whole table than to use the index.
If it is a large table, the index should be u
> For example: I have a table vm_message with an index on column msgid.
> Will the following do a sequential scan or an index?
>
> select count(*) from vm_message where msgid = 3;
How much of the table is that? How many rows? EXPLAIN ANALYSE will
tell you if you have the right plan (estimate
On Thu, Feb 23, 2006 at 01:44:43PM -0800, Kashmira Patel (kupatel) wrote:
> My understanding of this statement is that if I use count() without a
> WHERE clause, then essentially, it is applied to the entire table and
> hence requires a seq scan.
> But it should not require a seq scan if I have a c
Hello,
I am
using postgres version 7.4, and I read this in the
documentation:
"The aggregate
functions sum and count always require a sequential scan if applied to the
entire table."
My understanding of
this statement is that if I use count() without a WHERE clause, then
essentially