Why LIMIT after scanning the table?

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?"