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 histog
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
column
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:
> htt
On Thu, 17 Mar 2005 16:55:15 +0800, Christopher Kings-Lynne
<[EMAIL PROTECTED]> wrote:
>Make it deal with cross-table fk correlations as well :)
That's a different story. I guess it boils down to cross-column
statistics for a single table. Part of this is the correlation between
values in two or
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
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:
http://archives.postgresql.org/pgsql-hackers/2003-08/msg
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
Whoa Josh! I don't believe you're going to reduce the cost by 10 times
through a bit of tweaking - not without lowering the sequential scan
cost as well.
The only thing I can think of is perhaps his primary index drastically
needs repacking. Otherwise, isn't there a real anomaly here? Halving t
Daniel,
> Table "public.descriptionprodftdiclnk"
What is this, German? ;-)
> explain analyze select * from descriptionprodftdiclnk where idword=44;
> QUERY PLAN
> --
Hello.
I have a problem concerning multi-column indexes.
I have a table containing some 250k lines.
Table "public.descriptionprodftdiclnk"
Column| Type | Modifiers
-+-+---
idword | integer | not null
idqualifier | integer | not null
Indexes:
"description
10 matches
Mail list logo
