On Sun, 18 Feb 2007, Tom Lane wrote:
> We've repeatedly discussed getting rid of execution-time access to the
> Query structure --- here's one old message about it:
> and here's a recent one:
> I think it's time to bite the bullet and do that.
> The other big problem is the rangetable (rtable): currently it contains
> Query trees for subqueries (including views) so unless we clean that up
> we aren't going to be all that far ahead in terms of reducing the
> overhead. I'm envisioning creating a "compact" rangetable entry struct
> with just the fields the executor needs:
> eref (might only need the table alias name not the column names)
> and flattening subquery rangetables into the main list, so that there's
> just one list and rangetable indexes are unique throughout a plan tree.
> That will allow subqueries to execute with the same EState as the main
> query and thus simplify nodeSubplan and nodeSubqueryScan. This list
> will also provide a simple way for the plan cache module to know which
> relations to lock before determining whether the plan has been invalidated.
> Comments, objections? Also, any thoughts about the names to use for
> these new node types? As I commented last year, I'm not completely
> happy with "TopPlan" because it won't actually be a subtype of Plan,
> but I don't have a better idea. Also I'm unsure what to call the
> cut-down RangeTblEntry struct; maybe RunTimeRangeTblEntry?
I think TopPlan is misleading. What about MetaPlan instead of TopPlan? I
think RunTimeRangeTblEntry is okay, though long. ExecRangeTblEntry?
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly