On Thu, 17 Mar 2005 23:48:30 -0800, Ron Mayer
[EMAIL PROTECTED] wrote:
Would this also help estimates in the case where values in a table
are tightly clustered, though not in strictly ascending or descending
order?
No, I was just expanding the existing notion of correlation from single
columns to
On Thu, 17 Mar 2005 13:15:32 -0500, Tom Lane [EMAIL PROTECTED] wrote:
I am coming around to the view that we really do need to calculate
index-specific correlation numbers,
Correlation is a first step. We might also want distribution
information like number of distinct index tuples and
On Wed, 16 Mar 2005 22:19:13 -0500, Tom Lane [EMAIL PROTECTED] wrote:
calculate the correlation explicitly for each index
May be it's time to revisit an old proposal that has failed to catch
anybody's attention during the 7.4 beta period:
May be it's time to revisit an old proposal that has failed to catch
anybody's attention during the 7.4 beta period:
http://archives.postgresql.org/pgsql-hackers/2003-08/msg00937.php
I'm not sure I'd store index correlation in a separate table today.
You've invented something better for functional
Manfred Koizar [EMAIL PROTECTED] writes:
On Wed, 16 Mar 2005 22:19:13 -0500, Tom Lane [EMAIL PROTECTED] wrote:
calculate the correlation explicitly for each index
May be it's time to revisit an old proposal that has failed to catch
anybody's attention during the 7.4 beta period:
Daniel,
Table public.descriptionprodftdiclnk
What is this, German? ;-)
explain analyze select * from descriptionprodftdiclnk where idword=44;
QUERY PLAN
---
David Brown [EMAIL PROTECTED] writes:
Actually, I'm surprised the planner came up with such a low cost for the
single column index, unless ... perhaps correlation statistics aren't
used when determining costs for multi-column indexes?
The correlation calculation for multi-column indexes is
