Skip site navigation (1) Skip section navigation (2)

Re: Various performance questions

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Dror Matalon <dror(at)zapatec(dot)com>
Cc: Postgresql Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Various performance questions
Date: 2003-10-27 03:49:29
Message-ID: 87u15vxrue.fsf@stark.dyndns.tv (view raw or flat)
Thread:
Lists: pgsql-performance
Dror Matalon <dror(at)zapatec(dot)com> writes:

> explain analyze select count(*) from items where channel < 5000;
>                                                         QUERY PLAN
> --------------------------------------------------------------------------------------------------------------------------
>  Aggregate  (cost=249141.54..249141.54 rows=1 width=0) (actual time=26224.603..26224.608 rows=1 loops=1)
>    ->  Seq Scan on items  (cost=0.00..245377.52 rows=1505605 width=0) (actual time=7.599..17686.869 rows=1632057 loops=1)
>          Filter: (channel < 5000)
>  Total runtime: 26224.703 ms
> 
> 
> How can it do a sequential scan and apply a filter to it in less time
> than the full sequential scan? Is it actually using an index without
> really telling me? 

It's not using the index and not telling you. 

It's possible the count(*) operator itself is taking some time. Postgres
doesn't have to call it on the rows that don't match the where clause. How
long does "explain analyze select 1 from items" with and without the where
clause take?

What version of postgres is this?. In 7.4 (and maybe 7.3?) count() uses an
int8 to store its count so it's not limited to 4 billion records.
Unfortunately int8 is somewhat inefficient as it has to be dynamically
allocated repeatedly. It's possible it's making a noticeable difference,
especially with all the pages in cache, though I'm a bit surprised. There's
some thought about optimizing this in 7.5.

-- 
greg


In response to

Responses

pgsql-performance by date

Next:From: CHEWTCDate: 2003-10-27 04:27:29
Subject: Duplicate in pg_user table
Previous:From: Dror MatalonDate: 2003-10-26 19:44:50
Subject: Various performance questions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group