Message-ID: <4CF58DC5.5040101@catalyst.net.nz>
Date: Wed, 01 Dec 2010 12:50:29 +1300
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: SELECT INTO large FKyed table is slow
References: <4CF24103.8030209@megafon.hr> <4CF3522B.2050203@catalyst.net.nz>
	<4CF39CF4.2050506@megafon.hr> <op.vmxyi50oeorkce@apollo13>
In-Reply-To: <op.vmxyi50oeorkce@apollo13>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 30/11/10 05:53, Pierre C wrote:
>
>> Yes, since (sample_id, drone_id) is primary key, postgres created 
>> composite index on those columns. Are you suggesting I add two more 
>> indexes, one for drone_id and one for sample_id?
>
> (sample_id,drone_id) covers sample_id but if you make searches on 
> drone_id alone it is likely to be very slow since you got a large 
> number of sample_ids. Postgres can use any column of a multicolumn 
> index but it is only interesting performance-wise if the cardinality 
> of the first (ignored) columns is low. If you often make searches on 
> drone_id, create an index. But this isn't what is slowing your foreign 
> key checks.

Exactly, sorry - I was having a brain fade moment about which way your 
foreign key checks were going when I suggested adding those indexes... :-(