From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
---|---|
To: | "Decibel!" <decibel(at)decibel(dot)org> |
Subject: | Re: Interpreting statistics collector output |
Date: | 2007-08-18 15:00:32 |
Message-ID: | 46C70990.6040709@cheapcomplexdevices.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Decibel! wrote:
> On Aug 15, 2007, at 2:11 PM, Gregory Stark wrote:
>> "Decibel!" <decibel(at)decibel(dot)org> writes:
>>> On Wed, Aug 15, 2007 at 01:26:02PM -0400, Steve Madsen wrote:
>>>> On Aug 15, 2007, at 11:52 AM, Decibel! wrote:
>>>>> I can't really think of a case where a seqscan wouldn't return all the
>>>>> rows in the table... that's what it's meant to do.
>>
>> LIMIT
>
> Ok, you got me. :P But normally you wouldn't do a LIMIT without some
> kind of an ORDER BY, which would mean scanning the whole table.
Seems "where exists" does it too, no?
test=# explain analyze select 1 where exists (select * from bigtbl);
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
Result (cost=9681.61..9681.62 rows=1 width=0) (actual time=0.033..0.034 rows=1 loops=1)
One-Time Filter: $0
InitPlan
-> Seq Scan on bigtbl (cost=0.00..9681.61 rows=140461 width=443) (actual time=0.027..0.027 rows=1 loops=1)
Total runtime: 0.177 ms
(5 rows)
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Tolley | 2007-08-18 15:33:19 | Re: Partitioning |
Previous Message | Ron Johnson | 2007-08-18 14:59:18 | Re: Automating logins for mundane chores |