From: | aklaver(at)comcast(dot)net (Adrian Klaver) |
---|---|
To: | William Garrison <postgres(at)mobydisk(dot)com>, Postgres General List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Simple query not using index: why? |
Date: | 2008-09-03 17:47:30 |
Message-ID: | 090320081747.20246.48BECDB20000640A00004F1622007613949D0A900E04050E@comcast.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
-------------- Original message ----------------------
From: William Garrison <postgres(at)mobydisk(dot)com>
> I am looking for records with duplicate keys, so I am running this query:
>
> SELECT
> fileid, COUNT(*)
> FROM
> file
> GROUP BY
> fileid
> HAVING
> COUNT(*)>1
>
> The table has an index on fileid (non-unique index) so I am surprised
> that postgres is doing a table scan. This database is >15GB, and there
> are a number of fairly large string columns in the table. I am very
> surprised that scanning the index is not faster than scanning the
> table. Any thoughts on that? Is scanning the table faster than
> scanning the index? Is there a reason that it needs anything other than
> the index?
>
I may be missing something, but it would have to scan the entire table to get all the occurrences of each fileid in order to do the count(*).
--
Adrian Klaver
aklaver(at)comcast(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Devrim GÜNDÜZ | 2008-09-03 18:31:55 | Testers: 8.4 snapshot RPMs are available |
Previous Message | William Garrison | 2008-09-03 17:36:49 | Re: hash partitioning |