Why LIMIT after scanning the table? - Mailing list pgsql-performance

From Jim C. Nasby
Subject Why LIMIT after scanning the table?
Date
Msg-id 20030430010425.T66185@flake.decibel.org
Whole thread Raw
Responses Re: Why LIMIT after scanning the table?  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Re: Why LIMIT after scanning the table?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
I'm doing something where I just need to know if we have more than 100
rows in a table. Not wanting to scan the whole table, I thought I'd get
cute...

explain select count(*)
    FROM (SELECT * FROM email_rank WHERE project_id = :ProjectID LIMIT 100) AS t1;
                                     QUERY PLAN
-------------------------------------------------------------------------------------
 Aggregate  (cost=111.32..111.32 rows=1 width=48)
   ->  Subquery Scan t1  (cost=0.00..111.07 rows=100 width=48)
         ->  Limit  (cost=0.00..111.07 rows=100 width=48)
               ->  Seq Scan on email_rank  (cost=0.00..76017.40 rows=68439 width=48)
                     Filter: (project_id = 24)

The idea is that the inner-most query would only read the first 100 rows
it finds, then stop. Instead, if explain is to be believed (and speed
testing seems to indicate it's accurate), we'll read the entire table,
*then* pick the first 100 rows. Why is that?

FYI...

              Table "public.email_rank"
        Column         |  Type   |     Modifiers
-----------------------+---------+--------------------
 project_id            | integer | not null
 id                    | integer | not null
 first_date            | date    | not null
 last_date             | date    | not null
 day_rank              | integer | not null default 0
 day_rank_previous     | integer | not null default 0
 overall_rank          | integer | not null default 0
 overall_rank_previous | integer | not null default 0
 work_today            | bigint  | not null default 0
 work_total            | bigint  | not null default 0
Indexes: email_rank_pkey primary key btree (project_id, id),
         email_rank__day_rank btree (project_id, day_rank),
         email_rank__overall_rank btree (project_id, overall_rank)

--
Jim C. Nasby (aka Decibel!)                    jim@nasby.net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Query Plan far worse in 7.3.2 than 7.2.1
Next
From: Rajesh Kumar Mallah
Date:
Subject: Re: Is 292 inserts/sec acceptable performance ?