Skip site navigation (1) Skip section navigation (2)

Re: Avoiding a seq scan on a table.

From: "Daniel T(dot) Staal" <DStaal(at)usa(dot)net>
To: pgsql-novice(at)postgresql(dot)org
Subject: Re: Avoiding a seq scan on a table.
Date: 2008-01-14 17:55:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-novice
On Mon, January 14, 2008 12:35 pm, LWATCDR wrote:
> that is very odd since that table has 141 records in it.
> here is a different query that I ran.
> SELECT COUNT(*) FROM rma where terminatedate is NULL;
> This returns a value of 254 for the count but this is what I get from
> explain.
> Aggregate  (cost=219.77..219.78 rows=1 width=0)
>   ->  Seq Scan on rma  (cost=0.00..219.11 rows=264 width=0)
>         Filter: (terminatedate IS NULL)
> This says that rows =1 but returns 254 rows of data?
> The table contains over 7000 rows.

Spend some time reading this page:

This query returns one row: The _count_ of the number of rows.  This it
gets from a sequence scan, which that returns 264 rows, approximately. 
(The explain isn't doing the query itself, it is only looking at the
statistics it has, and telling you what it _would_ to, and estimating
costs based on that.)  That scan has a filter on it, you initial

In reality when you run the query it will return 254 rows in the scan, and
then do the 'count' aggregate operation on those.

In your original, the cost was ~12.  That's a very low cost, really.  It
is unlikely any index plan will beat that, regardless of the database. 
The above query would likely be sped up somewhat by an index, but how much
is a question.

A sequential scan is computationally cheap, and of predictable disk cost. 
An index scan is computationally much more expensive, has a somewhat
unpredictable disk cost, and has a non-zero startup cost.  The planner
will prefer the first unless it is sure the second will do better.

Daniel T. Staal

This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.

In response to

pgsql-novice by date

Next:From: Tom LaneDate: 2008-01-14 19:06:58
Subject: Re: Avoiding a seq scan on a table.
Previous:From: LWATCDRDate: 2008-01-14 17:35:30
Subject: Re: Avoiding a seq scan on a table.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group