Re: TopPlan, again

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