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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to