To: robins@pobox.com
cc: pgsql-performance@postgresql.org, "Paul Smith" <paullocal@pscs.co.uk>
Subject: Re: Index not being used in sorting of simple table 
In-reply-to: <36af4bed0705060537n38996591u1cab44fa067a4fea@mail.gmail.com> 
References: <VPOP32.5.0.20070504153630.092.309f.1.f0e0d0d3@lmail.pscs.co.uk>
	<3292.1178293381@sss.pgh.pa.us>
	<36af4bed0705060537n38996591u1cab44fa067a4fea@mail.gmail.com>
Comments: In-reply-to Robins <tharakan@gmail.com>
	message dated "Sun, 06 May 2007 18:07:45 +0530"
Date: Sun, 06 May 2007 20:35:56 -0400
Message-ID: <18314.1178498156@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Robins <tharakan@gmail.com> writes:
> There is one thing though, that I couldn't really understand. Considering
> that A's correlation in pg_stats being very high compared to B, isn't it 'a
> better candidate' for a sequential scan as compared to B in this scenario ?

No, high correlation reduces the cost of an indexscan but doesn't do
anything much for a seqscan-and-sort.  (Actually, I suppose it could
help by reducing the number of initial runs to be merged, but that's
not an effect the planner knows about.)  The interesting point is that
Paul shows

SELECT tablename, attname, correlation FROM pg_stats where tablename='x';
 x   | a  |     0.977819
 x   | b  |     0.78292

when his initial verbal description indicated that b should have the
better correlation.  So that's something else odd about this case.

			regards, tom lane