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?  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Needless additional partition check in INSERT?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Partitioning with temp tables is broken