Re: Question about index scan vs seq scan when using count() - Mailing list pgsql-sql

From Owen Jacobson
Subject Re: Question about index scan vs seq scan when using count()
Date
Msg-id 144D12D7DD4EC04F99241498BB4EEDCC234043@nelson.osl.com
Whole thread Raw
In response to Question about index scan vs seq scan when using count()  ("Kashmira Patel \(kupatel\)" <kupatel@cisco.com>)
List pgsql-sql
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 rows will fit on a single disk page.  The
indexwill be stored on a(t least one) separate disk page.  The cost of loading a page from disk pretty much swamps the
costof processing rows on a page, so in general the server tries to minimize the number of pages used.  To use an index
fora one-page table, it'd have to load two pages (the table and the index); to do a sequential scan over a one-page
tableit only has to load the table. 

Indexes are useful because they allow the DB to reduce the total number of pages loaded to complete a query.

-Owen


pgsql-sql by date:

Previous
From: "Kashmira Patel \(kupatel\)"
Date:
Subject: Re: Question about index scan vs seq scan when using count()
Next
From: Markus Schaber
Date:
Subject: CREATE TABLE AS and tablespaces