Re: Why LIMIT after scanning the table?

From: Jean-Luc Lachance <jllachan(at)nsd(dot)ca>
To: jim(at)nasby(dot)net
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Why LIMIT after scanning the table?
Date: 2003-04-30 16:23:11
Message-ID: 3EAFF86F.910A76EF@nsd.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

If you only what to know if there is more than 100 rows, why not do:

if exists (
SELECT 1 FROM email_rank WHERE project_id = :ProjectID OFFSET 100 LIMIT
1
)

"Jim C. Nasby" wrote:
>
> 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 () 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?"
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Diehl, Jeffrey 2003-04-30 16:34:40 Like search performance.
Previous Message Josh Berkus 2003-04-30 16:03:38 Re: [SQL] 7.3 analyze & vacuum analyze problem