Butkus_Charles@emc.com wrote:
>
> The cluster table only has 11 rows, so I'm not sure an index would
> help. The sensorreport table has 15,000,000 rows so that's why I've
> got the index there.
Ah - only 11?
>>>on the foreign key from sensortable.
>>>Again, is there any way to get the delete to use the
>>>idx_sensorreport_clusterid index?
>>
>>No, because this is the cluster table, not sensorreport :-)
>
> True, but the foreign key constraint on the sensorreport table forces
> Postgres to check if there are any sensorreport's that are currently
> using this cluster before allowing the cluster to be deleted.
If you only have 11 distinct values in the large table then it's
debatable whether it's always quicker to use the index. Since your first
example (clusterid = 25000114) returned so few rows, I'm guessing that
some other values represent a sizeable percentage of the table. That'd
explain the difference between PG's estimates and the actual number of
matching rows.
You can try "SET enable_seqscan =false;" before running the query and
see whether using the index helps things.
--
Richard Huxton
Archonet Ltd