From: Tom Lane <tgl@sss.pgh.pa.us>
To: Glyn Astill <glynastill@yahoo.co.uk>
cc: Pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Index scan cost calculation
In-reply-to: <412855216.18274544.1448560255082.JavaMail.yahoo@mail.yahoo.com>
References: <31151.1448556291@sss.pgh.pa.us>
 <412855216.18274544.1448560255082.JavaMail.yahoo@mail.yahoo.com>
Comments: In-reply-to Glyn Astill <glynastill@yahoo.co.uk>
 message dated "Thu, 26 Nov 2015 17:50:55 +0000"
Date: Thu, 26 Nov 2015 13:26:27 -0500
Message-ID: <6786.1448562387@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Glyn Astill <glynastill@yahoo.co.uk> writes:
>> From: Tom Lane <tgl@sss.pgh.pa.us>
>> The problem will probably go away by itself as your table grows, but
>> if you don't want to wait, you might want to reflect on which of the index
>> columns might be (partially?) functionally dependent on the other columns,
>> and whether you could redesign the key structure to avoid that.

> Many thanks for the explanation, is such a functional  dependency assumed purely based optimistically on statistics gathered by analyze?

Well, the point is that the selectivities associated with the individual
WHERE clauses are assumed independent, which allows us to just multiply
them together.  If they're not really independent then multiplication
gives a combined selectivity that's too small.  But without cross-column
statistics there's not much we can do to get a better estimate.

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance