ow wrote:
My impression was that the index "I_bca" covers the query, hence there should
not be a need to go to the table itself. Why would it?
Postgres always has to go to the table. The ability to read data
directly from indexes (ala other RDBMSs) has been discussed, but not
implemented. IIRC it
--- Joe Conway <[EMAIL PROTECTED]> wrote:
> >
> >>explain select b, c, a
> >>from test
> >>group by b, c, a
> >>having count(*) > 1
>
> Why would you expect this to use an index scan when it needs to read the
> entire table? If you read the whole table (or even a significant
> fraction of it),
On Sat, 29 Nov 2003, ow wrote:
> Am trying to find duplicate values in a large table (about 80M records).
> Somehow, none of the two (2) queries (see below) is using the index "I_bca"
> that, I believe, should've been used.
As a side note, to help determine if it should be used, you probably wan
jasiek wrote:
On Sat, 29 Nov 2003 08:49:24 -0800 (PST), ow wrote
explain select b, c, a
from test
group by b, c, a
having count(*) > 1
Why would you expect this to use an index scan when it needs to read the
entire table? If you read the whole table (or even a significant
fraction of it), a seq
ow <[EMAIL PROTECTED]> writes:
> Am trying to find duplicate values in a large table (about 80M records).
> Somehow, none of the two (2) queries (see below) is using the index "I_bca"
> that, I believe, should've been used.
Those plans are perfectly reasonable (particularly the GroupAggregate one)
On Sat, 29 Nov 2003 08:49:24 -0800 (PST), ow wrote
> explain select b, c, a
> from test
> group by b, c, a
> having count(*) > 1
I'm not sure about 7.4 aggregate improvements, but <=7.3 didn't work good
with aggregates at all. Maybe it's not directly an answer to your question,
but try theses qu
pgSql 7.4.0
Hi,
Am trying to find duplicate values in a large table (about 80M records).
Somehow, none of the two (2) queries (see below) is using the index "I_bca"
that, I believe, should've been used.
Any ideas? Thanks
--
CREATE
