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:
> http://archives.postgresql.org/pgsql-hackers/1999-02/msg00388.php
> and here's a recent one:
> http://archives.postgresql.org/pgsql-hackers/2006-08/msg00734.php
> I think it's time to bite the bullet and do that.
Great.
> 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:
>
> rtekind
> relid
> eref (might only need the table alias name not the column names)
> requiredPerms
> checkAsUser
>
> 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.
Cool.
> 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?
Thanks,
Gavin