From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | len(at)pdx(dot)edu |
Cc: | Mark Wong <markwkm(at)gmail(dot)com>, Postgresql PDX_Users <pdxpug(at)postgresql(dot)org>, David Maier <maier(at)cs(dot)pdx(dot)edu> |
Subject: | Re: 9/18 Visual Planner Meeting Wrapup |
Date: | 2008-10-22 16:52:01 |
Message-ID: | 1224694321.19961.37.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pdxpug |
On Wed, 2008-10-22 at 09:05 -0700, Len Shapiro wrote:
> The difficulty with your solutions is that they do not help an
> optimizer to determine the cardinality of a join. Consider the
> candidate-zip code example. The optimizer needs catalog information
> to determine cardinalities, and it is hoping that zip is a foreign
> key. It may be the case that, in some imaginary schema, zip is a
> foreign key. But that imaginary schema is not in the catalog for the
> optimizer to investigate. So the optimizer is SOL. That's my $.02,
> anyway.
>
I don't know what you mean by imaginary schema. You asked for a join,
which is an operation on value(s), so we'd have to find a join where
there is no reasonable design such that the join is a FK join.
And isn't it hard to determine the cardinality of any self join? That
would mean any self join would answer your problem. In fact, it seems
like all (or most) of the examples given can be expressed as a self join
in some reasonable database schema.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2008-10-22 16:52:55 | Re: 9/18 Visual Planner Meeting Wrapup |
Previous Message | Len Shapiro | 2008-10-22 16:05:41 | Re: 9/18 Visual Planner Meeting Wrapup |