Skip to content

Add new GUC gp_max_scan_on_shmem which replaced MAX_SCAN_ON_SHMEM#433

Merged
Stolb27 merged 1 commit into
adb-6.x-devfrom
ADBDEV-3180
Dec 22, 2022
Merged

Add new GUC gp_max_scan_on_shmem which replaced MAX_SCAN_ON_SHMEM#433
Stolb27 merged 1 commit into
adb-6.x-devfrom
ADBDEV-3180

Conversation

@red1452

@red1452 red1452 commented Nov 23, 2022

Copy link
Copy Markdown

New GUC specifies the limit of maximum scan node's instrumentations per query in shmem. If table has many partitions, Postgres planner will generate a plan with many SCAN nodes under a APPEND node. If the number of partitions are too many, this plan will occupy too many slots. Here is a limitation on number of shmem slots used by scan nodes for each backend. Instruments exceeding the limitation are allocated in local memory.

Here are some reminders before you submit the pull request

  • Add tests for the change
  • Document changes
  • Communicate in the mailing list if needed
  • Pass make installcheck
  • Review a PR in return to support the community

@red1452 red1452 changed the title Add new GUC gp_max_scan_on_shmem Add new GUC gp_max_scan_on_shmem which replaced MAX_SCAN_ON_SHMEM Nov 24, 2022
@red1452 red1452 marked this pull request as ready for review November 24, 2022 19:10
@red1452 red1452 requested a review from a team November 24, 2022 19:10
RekGRpth
RekGRpth previously approved these changes Nov 25, 2022
@red1452 red1452 requested a review from a team November 28, 2022 11:11
@InnerLife0

Copy link
Copy Markdown

I've checked all the places where new GUC was added and it seems all is correct.

The one thing I can suggest is to extend existed regression test (src/test/regress/sql/instr_in_shmem.sql) and test new GUC like it's done for GP_INSTRUMENT_SHMEM_SIZE.

@maksm90 maksm90 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't this GUC conflict with overall limit of shared memory for instrumentation objects gp_instrument_shmem_size? I.e. are we able allocate more intrumentations for SeqScan nodes in shared memory than shmem is available at all?

Comment thread gpdb-doc/dita/ref_guide/config_params/guc-list.xml Outdated
It repalced the hard-coded define MAX_SCAN_ON_SHMEM.
Specifies the limit of maximum scan node's instrumentations per query in shmem.
If table has many partitions, Postgres planner will generate a plan with many SCAN
nodes under a APPEND node. If the number of partitions are too many, this plan will
occupy too many slots. Here is a limitation on number of shmem slots used by scan
nodes for each backend. Instruments exceeding the limitation are allocated in local memory.
@Stolb27 Stolb27 merged commit 6425610 into adb-6.x-dev Dec 22, 2022
@Stolb27 Stolb27 deleted the ADBDEV-3180 branch December 22, 2022 04:54
This was referenced Jan 26, 2023
Stolb27 added a commit that referenced this pull request Mar 4, 2024
Stolb27 pushed a commit that referenced this pull request Mar 4, 2024
It repalced the hard-coded define MAX_SCAN_ON_SHMEM.
Specifies the limit of maximum scan node's instrumentations per query in shmem.
If table has many partitions, Postgres planner will generate a plan with many SCAN
nodes under a APPEND node. If the number of partitions are too many, this plan will
occupy too many slots. Here is a limitation on number of shmem slots used by scan
nodes for each backend. Instruments exceeding the limitation are allocated in local memory.

(cherry picked from commit 6425610)
Stolb27 added a commit that referenced this pull request Mar 14, 2024
Stolb27 pushed a commit that referenced this pull request Mar 14, 2024
It repalced the hard-coded define MAX_SCAN_ON_SHMEM.
Specifies the limit of maximum scan node's instrumentations per query in shmem.
If table has many partitions, Postgres planner will generate a plan with many SCAN
nodes under a APPEND node. If the number of partitions are too many, this plan will
occupy too many slots. Here is a limitation on number of shmem slots used by scan
nodes for each backend. Instruments exceeding the limitation are allocated in local memory.

(cherry picked from commit 6425610)
KnightMurloc pushed a commit that referenced this pull request Feb 3, 2025
It repalced the hard-coded define MAX_SCAN_ON_SHMEM.
Specifies the limit of maximum scan node's instrumentations per query in shmem.
If table has many partitions, Postgres planner will generate a plan with many
SCAN nodes under a APPEND node. If the number of partitions are too many, this
plan will occupy too many slots. Here is a limitation on number of shmem slots
used by scan nodes for each backend. Instruments exceeding the limitation are
allocated in local memory.

(cherry picked from commit 6425610)
KnightMurloc pushed a commit that referenced this pull request Feb 3, 2025
It repalced the hard-coded define MAX_SCAN_ON_SHMEM.
Specifies the limit of maximum scan node's instrumentations per query in shmem.
If table has many partitions, Postgres planner will generate a plan with many
SCAN nodes under a APPEND node. If the number of partitions are too many, this
plan will occupy too many slots. Here is a limitation on number of shmem slots
used by scan nodes for each backend. Instruments exceeding the limitation are
allocated in local memory.

(cherry picked from commit 6425610)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants