Thread: Re: QRY seems not using indexes

<morandell@gmail.com> writes
>
>
> so, if I do a qry like "EXPLAIN ANALYZE select * from pridecdr where
> idsede=8977758488" it tooks a lot of time before i get back any result:
>
> Index Scan using prd_id_sede on pridecdr  (cost=0.00..699079.90
> rows=181850 width=138) (actual time=51.241..483068.255 rows=150511
> loops=1)
>    Index Cond: (idsede = 8977758488::bigint)
>  Total runtime: 483355.325 ms
>

The query plan looks ok. Try to do EXPLAIN ANALYZE twice and see if there is
any difference. This could reduce the IO time to read your index/data since
you got enough RAM.

Also, if you haven't done VACUUM FULL for a long time, do so and compare the
difference.

Regards,
Qingqing

Qingqing Zhou wrote:
> <morandell@gmail.com> writes
>
>>
>>so, if I do a qry like "EXPLAIN ANALYZE select * from pridecdr where
>>idsede=8977758488" it tooks a lot of time before i get back any result:
>>
>>Index Scan using prd_id_sede on pridecdr  (cost=0.00..699079.90
>>rows=181850 width=138) (actual time=51.241..483068.255 rows=150511
>>loops=1)
>>   Index Cond: (idsede = 8977758488::bigint)
>> Total runtime: 483355.325 ms
>>
>
>
> The query plan looks ok. Try to do EXPLAIN ANALYZE twice and see if there is
> any difference. This could reduce the IO time to read your index/data since
> you got enough RAM.
>
> Also, if you haven't done VACUUM FULL for a long time, do so and compare the
> difference.
>

Could also be libpq buffering all 150000 rows before showing any.

It might be worthwhile using a CURSOR and doing 1 FETCH. If that is
quick, then buffering is probably the issue. BTW - do you really want
all the rows?

Cheers

Mark