refactoring planner data structures - Mailing list pgsql-hackers

From Tom Lane
Subject refactoring planner data structures
Date
Msg-id 5199.1117988122@sss.pgh.pa.us
Whole thread Raw
List pgsql-hackers
I'm intending to remove the "planner internal" fields of Query
(base_rel_list et al) and put them into a separate struct along
the lines of

typedef struct PlannerInfo
{   NodeTag     type;
   Query      *parse;            /* the Query being planned */
   List       *base_rel_list;    /* list of base-relation RelOptInfos */   List       *other_rel_list;   /* list of
other1-relation RelOptInfos */   List       *join_rel_list;    /* list of join-relation RelOptInfos */   ... etc ...
 
} PlannerInfo;

The planner's routines will all now pass one of these around instead
of a bare Query.  PlannerInfo will never go to disk, since it only
lives as long as the planning stage runs, and so this isn't an initdb
forcing change.  (We weren't writing the planner fields of Query to
disk anyway, which was ugly but necessary.)

I have several reasons for doing this: it's logically cleaner; it's
an essential first step towards someday making the planner not scribble
on its input; and I'm thinking of replacing join_rel_list with a
hashtable and would prefer not to expose that in something so widely
known as Query.

Any comments, objections?  This shouldn't affect any code outside the
planner, so AFAIK it won't break any patches-in-progress.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Havasvölgyi Ottó
Date:
Subject: Re: PGDN source browser
Next
From: Christopher Browne
Date:
Subject: Re: [PGF Members]Re: Google's Summer of Code ...