Sorry, I lost previous mail[1].
On Fri, 28 Dec 2018 at 20:36, Tsunakawa, Takayuki
<tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
> Although I may say the same thing as you, I think a natural idea would be to create a generic plan gradually. The
startingsimple question is "why do we have to touch all partitions at first?" That is, can we behave like this:
I also think creating a generic plan gradually is a better idea because planner should create a plan when it is
needed.
Any ideas?
On 2018-12-31 08:57:04, David Rowley wrote
>I imagine the place to start looking would be around why planning is so slow for that many partitions.
As you may already know, FLATCOPY at range_table_mutator has a large bottleneck.
Executing UPDATE, about npart squared RangeTblEntry is copied.
When I execute UPDATE to 100 partitioned table, FLATCOPY takes about 100 * 0.067 ms while total planning time takes
12.689ms.
On 2018-12-31 08:57:04, David Rowley wrote
>Another possible interesting idea would be to, instead of creating
>large Append/MergeAppend plans for partition scanning, invent some
>"Partition Seq Scan" and "Partition Index Scan" nodes that are able to
>build plans more similar to scanning a normal table. Likely such nodes
>would need to be programmed with a list of Oids that they're to scan
>during their execution. They'd also need to take care of their own
>tuple mapping for when partitions had their columns in varying orders.
Inventing some "Partition Seq Scan" and "Partition Index Scan" nodes is interesting.
It seems easy to add Scan nodes to each partition gradually.
[1]:CAKJS1f-y1HQK+VjG7=C==vGcLnzxjN8ysD5NmaN8Wh4=VsYipw@mail.gmail.com
regards,