agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables 7+ messages / 1 participants [nested] [flat]
* pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables @ 2026-09-18 05:14 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-09-18 05:14 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix pruning of DEFAULT partition in RANGE partitioned tables Some code added in 489247b0e tried to prune the DEFAULT partition when the next partition had a MINVALUE clause and likewise when the final partition to scan had a MAXVALUE clause for the final partition key in the pruning step. This code was incorrect as it could prune the default partition incorrectly in cases such as: p: PARTITION BY RANGE (a, b) p1: FOR VALUES FROM (13, 0) TO (19, MAXVALUE) pd: DEFAULT SELECT * FROM t WHERE a = 32 AND b >= -7; Here the pruning step for a = 32 and b >= -7 would see that only the default partition needs to be scan, but it would then see that the partition prior to the default had a MAXVALUE bound then prune away the default thinking that it needn't be scanned. This could result in incorrect results. Fix this by moving the code that looks for the MAXVALUE bound into the code handling BTEqualStrategyNumber so that when we're pruning with a prefix of the partition keys, we check if the bound for the offset we've calculated lands on a partition where the next partition key is bounded with MAXVALUE. If so we don't include the default partition. This leaves only the case of the first partition key. We handle that by modifying the existing code that was checking the last key covered by the given values. Author: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CAON2xHO=sqdqp=z8zWkybnWp0AuvefnAi2ez2vOYWrhXB6hHWQ@mail.gmail.com Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/b9d9e9bcc5786e48713d0d44de3f02c200bb7eff Modified Files -------------- src/backend/partitioning/partprune.c | 62 ++++++++++-------- src/test/regress/expected/partition_prune.out | 94 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 47 ++++++++++++++ 3 files changed, 177 insertions(+), 26 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables @ 2026-09-18 05:15 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-09-18 05:15 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix pruning of DEFAULT partition in RANGE partitioned tables Some code added in 489247b0e tried to prune the DEFAULT partition when the next partition had a MINVALUE clause and likewise when the final partition to scan had a MAXVALUE clause for the final partition key in the pruning step. This code was incorrect as it could prune the default partition incorrectly in cases such as: p: PARTITION BY RANGE (a, b) p1: FOR VALUES FROM (13, 0) TO (19, MAXVALUE) pd: DEFAULT SELECT * FROM t WHERE a = 32 AND b >= -7; Here the pruning step for a = 32 and b >= -7 would see that only the default partition needs to be scan, but it would then see that the partition prior to the default had a MAXVALUE bound then prune away the default thinking that it needn't be scanned. This could result in incorrect results. Fix this by moving the code that looks for the MAXVALUE bound into the code handling BTEqualStrategyNumber so that when we're pruning with a prefix of the partition keys, we check if the bound for the offset we've calculated lands on a partition where the next partition key is bounded with MAXVALUE. If so we don't include the default partition. This leaves only the case of the first partition key. We handle that by modifying the existing code that was checking the last key covered by the given values. Author: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CAON2xHO=sqdqp=z8zWkybnWp0AuvefnAi2ez2vOYWrhXB6hHWQ@mail.gmail.com Backpatch-through: 14 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/73b0b18f1f5dc9acf41e4033685148cdafb31d12 Modified Files -------------- src/backend/partitioning/partprune.c | 62 ++++++++++-------- src/test/regress/expected/partition_prune.out | 94 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 47 ++++++++++++++ 3 files changed, 177 insertions(+), 26 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables @ 2026-09-18 05:15 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-09-18 05:15 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix pruning of DEFAULT partition in RANGE partitioned tables Some code added in 489247b0e tried to prune the DEFAULT partition when the next partition had a MINVALUE clause and likewise when the final partition to scan had a MAXVALUE clause for the final partition key in the pruning step. This code was incorrect as it could prune the default partition incorrectly in cases such as: p: PARTITION BY RANGE (a, b) p1: FOR VALUES FROM (13, 0) TO (19, MAXVALUE) pd: DEFAULT SELECT * FROM t WHERE a = 32 AND b >= -7; Here the pruning step for a = 32 and b >= -7 would see that only the default partition needs to be scan, but it would then see that the partition prior to the default had a MAXVALUE bound then prune away the default thinking that it needn't be scanned. This could result in incorrect results. Fix this by moving the code that looks for the MAXVALUE bound into the code handling BTEqualStrategyNumber so that when we're pruning with a prefix of the partition keys, we check if the bound for the offset we've calculated lands on a partition where the next partition key is bounded with MAXVALUE. If so we don't include the default partition. This leaves only the case of the first partition key. We handle that by modifying the existing code that was checking the last key covered by the given values. Author: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CAON2xHO=sqdqp=z8zWkybnWp0AuvefnAi2ez2vOYWrhXB6hHWQ@mail.gmail.com Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/63d9e26c27b9965a78f0d59512a80d84935a7c4b Modified Files -------------- src/backend/partitioning/partprune.c | 62 ++++++++++-------- src/test/regress/expected/partition_prune.out | 94 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 47 ++++++++++++++ 3 files changed, 177 insertions(+), 26 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables @ 2026-09-18 05:16 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-09-18 05:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix pruning of DEFAULT partition in RANGE partitioned tables Some code added in 489247b0e tried to prune the DEFAULT partition when the next partition had a MINVALUE clause and likewise when the final partition to scan had a MAXVALUE clause for the final partition key in the pruning step. This code was incorrect as it could prune the default partition incorrectly in cases such as: p: PARTITION BY RANGE (a, b) p1: FOR VALUES FROM (13, 0) TO (19, MAXVALUE) pd: DEFAULT SELECT * FROM t WHERE a = 32 AND b >= -7; Here the pruning step for a = 32 and b >= -7 would see that only the default partition needs to be scan, but it would then see that the partition prior to the default had a MAXVALUE bound then prune away the default thinking that it needn't be scanned. This could result in incorrect results. Fix this by moving the code that looks for the MAXVALUE bound into the code handling BTEqualStrategyNumber so that when we're pruning with a prefix of the partition keys, we check if the bound for the offset we've calculated lands on a partition where the next partition key is bounded with MAXVALUE. If so we don't include the default partition. This leaves only the case of the first partition key. We handle that by modifying the existing code that was checking the last key covered by the given values. Author: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CAON2xHO=sqdqp=z8zWkybnWp0AuvefnAi2ez2vOYWrhXB6hHWQ@mail.gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d21d4f1ca0c44ecf9f75c0519e1c034d0fb3b630 Modified Files -------------- src/backend/partitioning/partprune.c | 62 ++++++++++-------- src/test/regress/expected/partition_prune.out | 94 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 47 ++++++++++++++ 3 files changed, 177 insertions(+), 26 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables @ 2026-09-18 05:16 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-09-18 05:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix pruning of DEFAULT partition in RANGE partitioned tables Some code added in 489247b0e tried to prune the DEFAULT partition when the next partition had a MINVALUE clause and likewise when the final partition to scan had a MAXVALUE clause for the final partition key in the pruning step. This code was incorrect as it could prune the default partition incorrectly in cases such as: p: PARTITION BY RANGE (a, b) p1: FOR VALUES FROM (13, 0) TO (19, MAXVALUE) pd: DEFAULT SELECT * FROM t WHERE a = 32 AND b >= -7; Here the pruning step for a = 32 and b >= -7 would see that only the default partition needs to be scan, but it would then see that the partition prior to the default had a MAXVALUE bound then prune away the default thinking that it needn't be scanned. This could result in incorrect results. Fix this by moving the code that looks for the MAXVALUE bound into the code handling BTEqualStrategyNumber so that when we're pruning with a prefix of the partition keys, we check if the bound for the offset we've calculated lands on a partition where the next partition key is bounded with MAXVALUE. If so we don't include the default partition. This leaves only the case of the first partition key. We handle that by modifying the existing code that was checking the last key covered by the given values. Author: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CAON2xHO=sqdqp=z8zWkybnWp0AuvefnAi2ez2vOYWrhXB6hHWQ@mail.gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1d8a9333693a2b8a4851bc33324fbc4873b72cd3 Modified Files -------------- src/backend/partitioning/partprune.c | 62 ++++++++++-------- src/test/regress/expected/partition_prune.out | 94 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 47 ++++++++++++++ 3 files changed, 177 insertions(+), 26 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables @ 2026-09-18 05:17 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-09-18 05:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix pruning of DEFAULT partition in RANGE partitioned tables Some code added in 489247b0e tried to prune the DEFAULT partition when the next partition had a MINVALUE clause and likewise when the final partition to scan had a MAXVALUE clause for the final partition key in the pruning step. This code was incorrect as it could prune the default partition incorrectly in cases such as: p: PARTITION BY RANGE (a, b) p1: FOR VALUES FROM (13, 0) TO (19, MAXVALUE) pd: DEFAULT SELECT * FROM t WHERE a = 32 AND b >= -7; Here the pruning step for a = 32 and b >= -7 would see that only the default partition needs to be scan, but it would then see that the partition prior to the default had a MAXVALUE bound then prune away the default thinking that it needn't be scanned. This could result in incorrect results. Fix this by moving the code that looks for the MAXVALUE bound into the code handling BTEqualStrategyNumber so that when we're pruning with a prefix of the partition keys, we check if the bound for the offset we've calculated lands on a partition where the next partition key is bounded with MAXVALUE. If so we don't include the default partition. This leaves only the case of the first partition key. We handle that by modifying the existing code that was checking the last key covered by the given values. Author: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CAON2xHO=sqdqp=z8zWkybnWp0AuvefnAi2ez2vOYWrhXB6hHWQ@mail.gmail.com Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9b8c0f23895268bf071143277d4b98ad34b90a05 Modified Files -------------- src/backend/partitioning/partprune.c | 62 ++++++++++-------- src/test/regress/expected/partition_prune.out | 94 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 47 ++++++++++++++ 3 files changed, 177 insertions(+), 26 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables @ 2026-09-18 05:17 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-09-18 05:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix pruning of DEFAULT partition in RANGE partitioned tables Some code added in 489247b0e tried to prune the DEFAULT partition when the next partition had a MINVALUE clause and likewise when the final partition to scan had a MAXVALUE clause for the final partition key in the pruning step. This code was incorrect as it could prune the default partition incorrectly in cases such as: p: PARTITION BY RANGE (a, b) p1: FOR VALUES FROM (13, 0) TO (19, MAXVALUE) pd: DEFAULT SELECT * FROM t WHERE a = 32 AND b >= -7; Here the pruning step for a = 32 and b >= -7 would see that only the default partition needs to be scan, but it would then see that the partition prior to the default had a MAXVALUE bound then prune away the default thinking that it needn't be scanned. This could result in incorrect results. Fix this by moving the code that looks for the MAXVALUE bound into the code handling BTEqualStrategyNumber so that when we're pruning with a prefix of the partition keys, we check if the bound for the offset we've calculated lands on a partition where the next partition key is bounded with MAXVALUE. If so we don't include the default partition. This leaves only the case of the first partition key. We handle that by modifying the existing code that was checking the last key covered by the given values. Author: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CAON2xHO=sqdqp=z8zWkybnWp0AuvefnAi2ez2vOYWrhXB6hHWQ@mail.gmail.com Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3d734a05977cff3a306a4624cfe604a992a546a0 Modified Files -------------- src/backend/partitioning/partprune.c | 62 ++++++++++-------- src/test/regress/expected/partition_prune.out | 94 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 47 ++++++++++++++ 3 files changed, 177 insertions(+), 26 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-09-18 05:17 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-09-18 05:14 pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables David Rowley <drowley@postgresql.org> 2026-09-18 05:15 pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables David Rowley <drowley@postgresql.org> 2026-09-18 05:15 pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables David Rowley <drowley@postgresql.org> 2026-09-18 05:16 pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables David Rowley <drowley@postgresql.org> 2026-09-18 05:16 pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables David Rowley <drowley@postgresql.org> 2026-09-18 05:17 pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables David Rowley <drowley@postgresql.org> 2026-09-18 05:17 pgsql: Fix pruning of DEFAULT partition in RANGE partitioned tables David Rowley <drowley@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox