Re: not using indexes on large table

From: "Dave Dutcher" <dave(at)tridecap(dot)com>
To: "'Jeroen Kleijer'" <jeroen(dot)kleijer(at)xs4all(dot)nl>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: not using indexes on large table
Date: 2007-04-23 14:56:46
Message-ID: 004601c785b7$9dda0950$0300000a@tridecap.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> From: pgsql-performance-owner(at)postgresql(dot)org
> [mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of
> Jeroen Kleijer
>
> The problems comes when I try to do a query without using a
> where clause
> because by then, it completely discards the indexes and does
> a complete
> table scan which takes over half an hour! (40.710.725 rows, 1110258
> pages, 1715 seconds)
>
> I've tried several things but doing a query like:
> select distinct volume from project_access_times
> or
> select distinct qtree from project_access_times
> always result in a full sequential table scan even after a
> 'vacuum' and
> 'vacuum analyze'.

To my knowledge Postgres doesn't use indexes for distinct queries or
grouping. Also you are getting horrible IO performance. Our old slow test
machine can scan a table of 12 million rows in 100 seconds, and our
production server can do the same in 20 seconds. If possible, I would try
running the same thing on your local hard drive. That way you can see how
much the netapp and NFS are slowing you down. Although in the end if you
need very fast distinct queries, you will need to maintain a separate table.

Dave

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Ron 2007-04-23 15:06:32 Re: postgres: 100% CPU utilization
Previous Message henk de wit 2007-04-23 11:35:26 Re: Redundant sub query triggers slow nested loop left join