TopPlan, again - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | TopPlan, again |
Date | |
Msg-id | 15162.1171840789@sss.pgh.pa.us Whole thread Raw |
Responses |
Re: TopPlan, again
(Gavin Sherry <swm@alcove.com.au>)
Re: TopPlan, again (Gregory Stark <stark@enterprisedb.com>) Re: TopPlan, again ("Simon Riggs" <simon@2ndquadrant.com>) |
List | pgsql-hackers |
While thinking about having a centralized plan cache for managing plan invalidation, I got annoyed again about the fact that the executor needs access to the Query tree. This means that we'll be storing *three* representations of any cached query: raw parsetree for possible regeneration, plus parsed Query tree and Plan tree. 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. After looking over the code it seems that the executor needs a limited subset of the Query fields, namely commandTypecanSetTagrtablereturningListreturningListsintointoOptionsintoOnCommit (why is this separate from intoOptions?)intoTableSpaceNamerowMarksresultRelationresultRelationsnParamExec(currently in topmost Plan node) which I think we should put into a new TopPlan node type. returningLists and resultRelations could be removed from Query; also, we might need only the list forms and not the singleton returningList/resultRelation fields in TopPlan. 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: rtekindrelideref (might only need the table alias name not the column names)requiredPermscheckAsUser 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? regards, tom lane
pgsql-hackers by date: