Re: broken join optimization? (8.0)

> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Michael Fuhr <mike(at)fuhr(dot)org> writes:
> > On Tue, Oct 25, 2005 at 04:56:11PM -0700, chester c young wrote:
> >> in php (for example) it's frequently nice to get the structure of
> >> table without any data,
>
> > Have you considered "SELECT * FROM mytable LIMIT 0"?
>
> Indeed.

i think i misled: the goal is to retrieve _one_ row where the value of
each attribute is null. this can be done laborously using meta data,
but is done quite niftily using a left join against one row.

> > I see the same behavior in the latest 8.1beta code. Maybe one of
> > the developers will comment on whether optimizing that is a simple
> > change, a difficult change, not worth changing because few people
> > find a use for it, or a behavior that can't be changed because of
> > something we're not considering.
>
> Not worth changing --- why should we expend cycles (even if it only
> takes a few, which isn't clear to me offhand) on every join query, to
> detect what's simply a brain-dead way of finding out table structure?

again, the goal is a quick way to retrieve one row from a table where
each attribute value is null, NOT to get the table structure.

> I can't think of any realistic scenarios for a constant-false join
> clause.

i would like a better idea on how to retrieve one row from a table
where the value of each attribute is null - i felt this a perfectly
good use of sql.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com