Re: Interpreting statistics collector output

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)

In response to

Browse pgsql-general by date

  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