| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Andreas Kretschmer <andreas(at)a-kretschmer(dot)de> |
| Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: bug in PG13? |
| Date: | 2020-11-02 01:01:39 |
| Message-ID: | CAApHDvquB1YG9rb1o3MaMN4pG+A2AmYajjYni_y2ZDh=cG-CmA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, 15 Oct 2020 at 03:53, Andreas Kretschmer
<andreas(at)a-kretschmer(dot)de> wrote:
> it seems to me a bug. i have a partitioned table:
I've just pushed a fix [1] for this to master only (PG14+)
The problem was that we only added the required information to allow
the executor to perform run-time pruning to the Append/MergeAppend for
the top-level Append. The example you've given actually did have a
nested-Append at one point during planning. However, since the
top-level Append only had a single sub-plan, it was removed and that
single sub-plan was used instead. Since that single sub-plan happened
to be an Append, there was no run-time pruning information to allow
the executor to prune away the unneeded partitions.
The fix for this was a bit too invasive to go backpatching it.
Run-time pruning was coded purposefully to only prune on the top-level
Append/Merge Append. In hindsight, that was likely a bad choice, but
it was the choice that was made originally, so I'm leaning towards not
classing this as a bug. After thinking about this all over again, it
seems there are more legitimate reasons to have nested Append/Merge
Appends than I had thought when I was originally working on run-time
pruning, so it makes sense to allow run-time pruning on those to work
going forward.
Thanks for the report.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | paras paliya | 2020-11-02 09:53:06 | Last updated time for a Schema of the table |
| Previous Message | Rich Shepard | 2020-11-01 23:26:45 | Re: Another user error? [RESOLVING] |