From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Christopher Browne <cbbrowne(at)acm(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Various performance questions |
Date: | 2003-10-27 15:09:09 |
Message-ID: | 87oew2yay2.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Christopher Browne <cbbrowne(at)acm(dot)org> writes:
> In the last exciting episode, dror(at)zapatec(dot)com (Dror Matalon) wrote:
> > I was answering an earlier response that suggested that maybe the actual
> > counting took time so it would take quite a bit longer when there are
> > more rows to count.
That was my theory. I guess it's wrong. There is other work involved in
processing a record, but i'm surprised it's as long as the work to actually
pull the record from kernel and check if it's visible.
> Well, if a "where clause" allows the system to use an index to search
> for the subset of elements, that would reduce the number of pages that
> have to be examined, thereby diminishing the amount of work.
it's not. therein lies the mystery.
> Why don't you report what EXPLAIN ANALYZE returns as output for the
> query with WHERE clause? That would allow us to get more of an idea
> of what is going on...
He did, right at the start of the thread.
For a 1 million record table without he's seeing
select 1 from tab
select count(*) from tab
being comparable with only a slight delay for the count(*) whereas
select 1 from tab where c < 1000
select count(*) from tab where c < 1000
are much faster even though they still use a sequential scan.
I'm puzzled why the where clause speeds things up as much as it does.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tarhon-Onu Victor | 2003-10-27 15:15:05 | Re: Various performance questions |
Previous Message | Christopher Browne | 2003-10-27 12:52:06 | Re: Various performance questions |