From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: why partition pruning doesn't work? |
Date: | 2018-06-15 08:39:02 |
Message-ID: | 56f1556c-6d6e-aaf8-de4f-a790a1efa5a3@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018/06/14 23:40, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Jun 14, 2018 at 7:23 AM, David Rowley
>> <david(dot)rowley(at)2ndquadrant(dot)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.
The patch I mentioned upthread maintains an array of Relation pointers in
AppendState with as many members as there are in the partitioned_rels list
that appears in the corresponding Append plan.
I revised that patch a bit to rename ExecLockNonLeafAppendTables to
ExecOpenAppendPartitionedTables to sound consistent with
ExecOpenScanRelation et al.
Thanks,
Amit
Attachment | Content-Type | Size |
---|---|---|
0001-Open-partitioned-tables-during-Append-initialization.patch | text/plain | 13.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Antonin Houska | 2018-06-15 08:42:33 | Re: Memory leaks in BufFileOpenShared() |
Previous Message | Amit Langote | 2018-06-15 08:37:49 | Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian |