diff options
author | David Rowley <drowley@postgresql.org> | 2021-04-08 22:35:48 +1200 |
---|---|---|
committer | David Rowley <drowley@postgresql.org> | 2021-04-08 22:35:48 +1200 |
commit | 5ac9c4307337313bedeafc21dbbab93ba809241c (patch) | |
tree | e7698b1369ba2fd88fd92cce0fccb4c331a97723 /src/backend/access/transam/xlogreader.c | |
parent | 7e3c54168d9ec058cb3c9d47f8105b1d32dc8ceb (diff) | |
download | postgresql-5ac9c4307337313bedeafc21dbbab93ba809241c.tar.gz postgresql-5ac9c4307337313bedeafc21dbbab93ba809241c.zip |
Cleanup partition pruning step generation
There was some code in gen_prune_steps_from_opexps that needlessly
checked a list was not empty when it clearly had to contain at least one
item. This prompted a further cleanup operation in partprune.c.
Additionally, the previous code could end up adding additional needless
INTERSECT steps. However, those do not appear to be able to cause any
misbehavior.
gen_prune_steps_from_opexps is now no longer in charge of generating
combine pruning steps. Instead, gen_partprune_steps_internal, which
already does some combine step creation has been given the sole
responsibility of generating all combine steps. This means that when
we recursively call gen_partprune_steps_internal, since it always now adds
a combine step when it produces multiple steps, we can just pay attention
to the final step returned.
In passing, do quite a bit of work on the comments to try to more clearly
explain the role of both gen_partprune_steps_internal and
gen_prune_steps_from_opexps. This is fairly complex code so some extra
effort to give any new readers an overview of how things work seems like
a good idea.
Author: Amit Langote
Reported-by: Andy Fan
Reviewed-by: Kyotaro Horiguchi, Andy Fan, Ryan Lambert, David Rowley
Discussion: https://postgr.es/m/CAKU4AWqWoVii+bRTeBQmeVW+PznkdO8DfbwqNsu9Gj4ubt9A6w@mail.gmail.com
Diffstat (limited to 'src/backend/access/transam/xlogreader.c')
0 files changed, 0 insertions, 0 deletions