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

Why LIMIT after scanning the table?

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: pgsql-performance(at)postgresql(dot)org
Subject: Why LIMIT after scanning the table?
Date: 2003-04-30 06:04:25
Message-ID: 20030430010425.T66185@flake.decibel.org (view raw or flat)
Thread:
Lists: 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(at)nasby(dot)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?"


Responses

pgsql-performance by date

Next:From: Rajesh Kumar MallahDate: 2003-04-30 07:39:53
Subject: Re: Is 292 inserts/sec acceptable performance ?
Previous:From: Tom LaneDate: 2003-04-29 23:05:53
Subject: Re: Query Plan far worse in 7.3.2 than 7.2.1

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