refactoring planner data structures

Поиск
Список
Период
Сортировка
От Tom Lane
Тема refactoring planner data structures
Дата
Msg-id 5199.1117988122@sss.pgh.pa.us
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Havasvölgyi Ottó
Дата:
Сообщение: Re: PGDN source browser
Следующее
От: Christopher Browne
Дата:
Сообщение: Re: [PGF Members]Re: Google's Summer of Code ...