Re: broken join optimization? (8.0)

> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Michael Fuhr <mike@fuhr.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