Re: why partition pruning doesn't work?
От | Tom Lane |
---|---|
Тема | Re: why partition pruning doesn't work? |
Дата | |
Msg-id | 27099.1528987211@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: why partition pruning doesn't work? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: why partition pruning doesn't work?
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Jun 14, 2018 at 7:23 AM, David Rowley > <david.rowley@2ndquadrant.com> wrote: >> However, I only spent about 10 mins looking into this, there may be >> some giant holes in the idea. It would need much more research. > It kind of flies in the face of the idea that a RangeTblEntry is just > a node that can be freely copied around, serialized and deserialized, > etc. And also the idea that the Plan tree is read-only to the executor, which is not a good property to give up. > I think it would be better to keep the pointer in the RelOptInfo in > the planner and in the EState or PlanState in the executor. Those are > things we don't think can be copied, serialized, etc. Yeah, RelOptInfo seems like the natural place in the planner; we might need index relcache links in IndexOptInfo, too. I'm less sure what to do in the executor. We already do keep open relation pointers in PlanStates; the problem is just that it's node-type-specific (ss_currentRelation, iss_RelationDesc, etc). Perhaps that's unavoidable and we should just add more such fields as needed. regards, tom lane
В списке pgsql-hackers по дате отправления: