Skip site navigation (1) Skip section navigation (2)

Re: Joins, Deletes and Indexes

From: Richard Huxton <dev(at)archonet(dot)com>
To: Butkus_Charles(at)emc(dot)com
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Joins, Deletes and Indexes
Date: 2005-02-23 13:42:18
Message-ID: 421C883A.20708@archonet.com (view raw or flat)
Thread:
Lists: pgsql-performance
Butkus_Charles(at)emc(dot)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

In response to

pgsql-performance by date

Next:From: Markus SchaberDate: 2005-02-23 14:37:48
Subject: Re: PostgreSQL is extremely slow on Windows
Previous:From: Butkus_CharlesDate: 2005-02-23 13:06:08
Subject: Re: Joins, Deletes and Indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group