From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Parallel Append can break run-time partition pruning |
Date: | 2020-10-15 14:01:23 |
Message-ID: | CA+HiwqHG=wtEzjG0+7n8wemCbqOrzro7+s1zq-Zq8yF-F2zysQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert forwarded me a link to an email sent to -general list, where
the reported problem seems to be the same problem that was being
discussed here.
https://www.postgresql.org/message-id/flat/d0f6d811-8946-eb9f-68e2-1a8a7f80ff21%40a-kretschmer.de
Going over the last few emails, it seems that David held off from
committing the patch, because of the lack of confidence in its
robustness. With the patch, a sub-partitioned child's partial
Append's child paths will *always* be pulled up into the parent's set
of partial child paths thus preventing the nesting of Appends, which
the run-time pruning code can't currently cope with. The lack of
confidence seems to be due to the fact that always pulling up a
sub-Append's child paths into the parent partial Append's child paths
*may* cause the latter to behave wrongly under parallelism and the new
code structure will prevent add_partial_path() from being the
arbitrator of whether such a path is really the best in terms of cost.
If we can't be confident in that approach, maybe we should consider
making the run-time pruning code cope with nested Appends?
--
Amit Langote
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-10-15 14:03:46 | Re: Aw: Re: Minor documentation error regarding streaming replication protocol |
Previous Message | Andy Fan | 2020-10-15 13:12:19 | improve the algorithm cached_plan_cost with real planning time? |