Re: Seq Scan - Mailing list pgsql-general

From John D. Burger
Subject Re: Seq Scan
Date
Msg-id 2E99D81C-596B-473D-8555-750AF0CC182A@mitre.org
Whole thread Raw
In response to Seq Scan  ("Tyler Durden" <tylersticky@gmail.com>)
Responses Re: Seq Scan  ("Tyler Durden" <tylersticky@gmail.com>)
List pgsql-general
Tyler Durden wrote:

> I'm having some problems in performance in a simple select count(id)
> from.... I have 700 000 records in one table, and when I do:
>
> # explain select (id) from table_name;
> -[ RECORD
> 1 ]----------------------------------------------------------------
> QUERY PLAN | Seq Scan on table_name  (cost=0.00..8601.30
> rows=266730 width=4)
>
> I had created an index for id(btree), but still shows "Seq Scan".
> What I'm doing wrong?

You mention SELECT COUNT(ID), but your example shows SELECT ID.  In
either case, the planner is choosing the correct plan.  Indexes exist
to save the engine from visiting every row in the table, but both of
these queries require every row to be visited anyway.

Perhaps you think that these queries can be satisfied without
visiting the actual table rows at all, using only the index.  This is
incorrect - PG doesn't work that way.

- John Burger
   MITRE


pgsql-general by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: warm standby server stops doingcheckpointsafterawhile
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Seq Scan