Обсуждение: Runtime partition pruning for MergeAppend
Back in the v11 cycle, there was just not quite enough time to get the MergeAppend run-time partition pruning patch in. I've attached v24 of this patch. The only changes done from v23 [1] are to re-base the patch atop of current master. There's was a bit of churn in the partition pruning and run-time pruning code last week. I've re-aligned the new code to account for the work done there. I'll add this to the July 'fest. [1] https://www.postgresql.org/message-id/CAKJS1f_yFC8vVLd3mHP4pxhRgPRKb9hqa4Zv+5v5pko6f038dA@mail.gmail.com -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
On 18/06/18 13:29, David Rowley wrote: > Back in the v11 cycle, there was just not quite enough time to get the > MergeAppend run-time partition pruning patch in. > > I've attached v24 of this patch. The only changes done from v23 [1] > are to re-base the patch atop of current master. There's was a bit of > churn in the partition pruning and run-time pruning code last week. > I've re-aligned the new code to account for the work done there. Looks solid. The only actual bug I see is that this doesn't honor the enable_partition_pruning GUC, but that's trivial to fix. So fixed that, reworded some of the comments a tiny bit, and committed. Thanks! - Heikki
Hi
2018-07-19 12:50 GMT+02:00 Heikki Linnakangas <hlinnaka@iki.fi>:
On 18/06/18 13:29, David Rowley wrote:Back in the v11 cycle, there was just not quite enough time to get the
MergeAppend run-time partition pruning patch in.
I've attached v24 of this patch. The only changes done from v23 [1]
are to re-base the patch atop of current master. There's was a bit of
churn in the partition pruning and run-time pruning code last week.
I've re-aligned the new code to account for the work done there.
Looks solid. The only actual bug I see is that this doesn't honor the enable_partition_pruning GUC, but that's trivial to fix. So fixed that, reworded some of the comments a tiny bit, and committed. Thanks!
small note
for getting custom plan, you don't need execute 5x now. Just use plan_cache_mode GUC.
Regards
Pavel
- Heikki
On 19 July 2018 at 22:50, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > Looks solid. The only actual bug I see is that this doesn't honor the > enable_partition_pruning GUC, but that's trivial to fix. So fixed that, > reworded some of the comments a tiny bit, and committed. Thanks! Many thanks for fixing that and pushing. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 19 July 2018 at 23:22, Pavel Stehule <pavel.stehule@gmail.com> wrote: > for getting custom plan, you don't need execute 5x now. Just use > plan_cache_mode GUC. Yeah. It's good to see that patch in. I wonder if we should go and change those tests to get rid of the 5x EXECUTEs before the actual test. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 19 July 2018 at 22:50, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > Looks solid. The only actual bug I see is that this doesn't honor the > enable_partition_pruning GUC, but that's trivial to fix. So fixed that, > reworded some of the comments a tiny bit, and committed. Thanks! I just noticed I managed to miss updating "Append" to "MergeAppend" when copying a comment out of nodeAppend.c into nodeMergeAppend.c. I see you noticed it but accidentally updated the comment in nodeAppend.c. The attached fixes. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
On 19/07/18 15:36, David Rowley wrote: > I just noticed I managed to miss updating "Append" to "MergeAppend" > when copying a comment out of nodeAppend.c into nodeMergeAppend.c. I > see you noticed it but accidentally updated the comment in > nodeAppend.c. D'oh! Fixed, thanks. - Heikki