This should read:
> Considering that the FK part is unique, the
^^PK^^
> skewness in the relationship is completely determined by the FK part's
> histogram. That would give at least a lower/upper bound and MCVs to the
> relationship.
Cheers,
Csaba.
On Tue, 2007-03-20 at 18:12, Josh Berkus wrote:
> Tom,
>
> > Actually, I think you don't particularly need stats for that in most
> > cases --- if the planner simply took note that the FK relationship
> > exists, it would know that each row of the FK side joins to exactly
> > one row of the PK sid
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> It might be worth coming up with a different means to store the
> histogram for the multi-column case.
A separate array for each column involved seems a whole lot less
fragile than pretending we can handle mixed-type arrays.
We probably need a differen
On Mon, Mar 19, 2007 at 06:55:56PM -0700, Jeff Davis wrote:
> On Mon, 2007-03-19 at 21:24 -0400, Tom Lane wrote:
> > Jeff Davis <[EMAIL PROTECTED]> writes:
> > > We can already keep stats for a functional index. Is there a reason we
> > > can't keep stats for a multi-column index?
> >
> > The ques
Josh Berkus writes:
>> Actually, I think you don't particularly need stats for that in most
>> cases --- if the planner simply took note that the FK relationship
>> exists, it would know that each row of the FK side joins to exactly
>> one row of the PK side, which in typical cases is sufficient.
On Tue, 2007-03-20 at 18:12 +0100, Josh Berkus wrote:
> Tom,
>
> > Actually, I think you don't particularly need stats for that in most
> > cases --- if the planner simply took note that the FK relationship
> > exists, it would know that each row of the FK side joins to exactly
> > one row of the
On Tue, 2007-03-20 at 09:03 +, Simon Riggs wrote:
> We should allow the DBA to specify which groups of cols to keep
> statistics on, if there is no index on that group.
>
> That solves the combinatorial explosion problem.
>
I think it would be a good first step if we could just keep stats on
Tom,
Actually, I think you don't particularly need stats for that in most
cases --- if the planner simply took note that the FK relationship
exists, it would know that each row of the FK side joins to exactly
one row of the PK side, which in typical cases is sufficient.
Is it? What about the
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> It was also suggested that column pairs in FK relationship could be
> automatically enabled. So you don't need to specify those manually.
Actually, I think you don't particularly need stats for that in most
cases --- if the planner simply took note tha
Alvaro Herrera wrote:
> Now, the hard question is deciding what to keep track of. I don't
> think MCV makes much sense, because what's the MCV of two columns?
The combination that occurs most often.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end o
Richard Huxton wrote:
> Simon Riggs wrote:
> >On Tue, 2007-03-20 at 14:14 +1200, Mark Kirkwood wrote:
> >>Jeff Davis wrote:
> >>>I know we can't keep stats on every combination of columns. My initial
> >>>idea would be to only keep stats about a multi-column index (and
> >>>probably optional for th
Simon Riggs wrote:
On Tue, 2007-03-20 at 14:14 +1200, Mark Kirkwood wrote:
Jeff Davis wrote:
I know we can't keep stats on every combination of columns. My initial
idea would be to only keep stats about a multi-column index (and
probably optional for those, too).
Maybe you would want to keep s
On Tue, 2007-03-20 at 14:14 +1200, Mark Kirkwood wrote:
> Jeff Davis wrote:
> >
> > I know we can't keep stats on every combination of columns. My initial
> > idea would be to only keep stats about a multi-column index (and
> > probably optional for those, too).
> >
>
> Maybe you would want to ke
Jeff Davis wrote:
I know we can't keep stats on every combination of columns. My initial
idea would be to only keep stats about a multi-column index (and
probably optional for those, too).
Maybe you would want to keep single column indexes too, so that (more)
accurate estimates for bitmap-an
On Mon, 2007-03-19 at 21:24 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > We can already keep stats for a functional index. Is there a reason we
> > can't keep stats for a multi-column index?
>
> The questions that need to be answered are (1) what stats are you gonna
> collec
Jeff Davis <[EMAIL PROTECTED]> writes:
> We can already keep stats for a functional index. Is there a reason we
> can't keep stats for a multi-column index?
The questions that need to be answered are (1) what stats are you gonna
collect, and (2) exactly what are you going to do with them when you
I know the idea has come up a few times to do cross-column statistics to
improve plans when the data distributions are dependent. I found a
couple references in the archives:
http://archives.postgresql.org/pgsql-hackers/2006-09/msg02118.php
http://archives.postgresql.org/pgsql-hackers/2006-08/msg0
17 matches
Mail list logo
