| 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: | Whole Thread | Raw Message | 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 |