From: | wieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) |
Cc: | wieck(at)debis(dot)com, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Planner drops unreferenced tables --- bug, no? |
Date: | 1999-09-29 15:16:18 |
Message-ID: | m11WLSs-0003kLC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> wieck(at)debis(dot)com (Jan Wieck) writes:
> >> It seems to me that the latter query must yield 9 rows (three
> >> occurrences of each value) to satisfy the SQL spec. The spec defines
> >> the result of a two-query FROM clause to be the Cartesian product of the
> >> two tables, period. It doesn't say anything about "only if one or more
> >> columns of each table are actually used somewhere".
>
> > Caution here!
>
> > After rewriting there can be many unused rangetable entries
> > floating around. Especially if you SELECT from a view, the
> > view's relation is still mentioned in the rangetable.
>
> I was thinking of forcing rangetable entries that are marked as
> 'inFromCl' to be included in the planner's target relation set,
> but those not so marked would only get added if referenced, same as now.
> Do you think that will not work?
I'm not sure and don't have the time to dive into. Just
wanted to point on an area of (maybe unexpected) side
effects.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Don Baccus | 1999-09-29 15:21:58 | Re: [HACKERS] Planner drops unreferenced tables --- bug, no? |
Previous Message | Thomas Lockhart | 1999-09-29 15:07:53 | Re: New notices? |