> 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
>>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
You can try "SET enable_seqscan =false;" before running the query and
see whether using the index helps things.
In response to
pgsql-performance by date
|Next:||From: Markus Schaber||Date: 2005-02-23 14:37:48|
|Subject: Re: PostgreSQL is extremely slow on Windows|
|Previous:||From: Butkus_Charles||Date: 2005-02-23 13:06:08|
|Subject: Re: Joins, Deletes and Indexes|