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
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 |