Re: generic plans and "initial" pruning
От | Amit Langote |
---|---|
Тема | Re: generic plans and "initial" pruning |
Дата | |
Msg-id | CA+HiwqGf5PrQ8RX2So7g0y75xN_jVs6W0pvfUKv6zS+KYMGsig@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: generic plans and "initial" pruning (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, Apr 1, 2022 at 12:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Amit Langote <amitlangote09@gmail.com> writes: > > On Fri, Apr 1, 2022 at 10:32 AM David Rowley <dgrowleyml@gmail.com> wrote: > >> 1. You've changed the signature of various functions by adding > >> ExecLockRelsInfo *execlockrelsinfo. I'm wondering why you didn't just > >> put the ExecLockRelsInfo as a new field in PlannedStmt? > > > I'm worried about that churn myself and did consider this idea, though > > I couldn't shake the feeling that it's maybe wrong to put something in > > PlannedStmt that the planner itself doesn't produce. > > PlannedStmt is part of the plan tree, which MUST be read-only to > the executor. This is not negotiable. However, there's other > places that this data could be put, such as QueryDesc. > Or for that matter, couldn't the data structure be created by > the planner? (It looks like David is proposing exactly that > further down.) The data structure in question is for storing the results of performing initial partition pruning on a generic plan, which the proposes to do in plancache.c -- inside the body of AcquireExecutorLocks()'s loop over PlannedStmts -- so, it's hard to see it as a product of the planner. :-( -- Amit Langote EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: