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 ---------------------------(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