Re: Index not being used in sorting of simple table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: robins(at)pobox(dot)com
Cc: pgsql-performance(at)postgresql(dot)org, "Paul Smith" <paullocal(at)pscs(dot)co(dot)uk>
Subject: Re: Index not being used in sorting of simple table
Date: 2007-05-07 00:35:56
Message-ID: 18314.1178498156@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Robins <tharakan(at)gmail(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Ambrus Wagner (IJ/ETH) 2007-05-07 13:05:58 Merging large volumes of data
Previous Message Robins 2007-05-06 12:37:45 Re: Index not being used in sorting of simple table