Re: no index-usage on aggregate-functions? - Mailing list pgsql-performance

From Harald Lau (Sector-X)
Subject Re: no index-usage on aggregate-functions?
Date
Msg-id 00b801c45db5$914330e0$6602a8c0@spock
Whole thread Raw
In response to no index-usage on aggregate-functions?  ("Harald Lau (Sector-X)" <harald@sector-x.de>)
Responses Re: no index-usage on aggregate-functions?  (Dennis Bjorklund <db@zigo.dhs.org>)
Re: no index-usage on aggregate-functions?  (Bruno Wolff III <bruno@wolff.to>)
Re: no index-usage on aggregate-functions?  ("Scott Marlowe" <smarlowe@qwest.net>)
List pgsql-performance
@Chris:

> > SELECT count(*) FROM the_table
> > => Seq scan -> takes about 12 sec
> This cannot be made O(1) in postgres due to MVCC.  You just have to live
> with it.

bad news
BTW: in this case you could workaround
select reltuples from pg_class where relname='the_table'
(yes, I know: presumes a regular vacuum analyse)

> Average and sum can never use an index AFAIK, in any db server.  You
> need information from every row.

Take a look at the SQLSrv-pendant:
create index x_1 on the_table (num_found)
select avg(num_found) from the_table
-> Index Scan(OBJECT:([midata].[dbo].[THE_TABLE].[x_1])

(I'm not sure what Oracle does - have to re-install it first ...)


@Scott:
> Yes, you're expecting an MVCC database to behave like a row locking
> database.

hmmmm...
So, it seems that PG is not soooo well suited for a datawarehouse and/or performing extensive
statistics/calculations/reportingson large tables, is it? 

Greetings Harald

pgsql-performance by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Query performance
Next
From: Dennis Bjorklund
Date:
Subject: Re: no index-usage on aggregate-functions?