Progressive visibility mapping upgrading and freezing optimization method for database

Abstract

The invention discloses a progressive visibility mapping upgrading and freezing optimization method and device for a database. The method comprises the following steps of: additionally arranging a PDVMFROZEN flag bit at the head of a visibility mapping VM block to mark a new version (including all-frozen bit); setting a vmversion field in a table memory structure Relation, and dynamically detecting new and old VM versions; modifying a VM interface and adding a VMALLFROZEN macro compatible new version and an old version; automatically marking a new version for the new VM block, and gradually upgrading the old VM block; in the VACUUM process, a frozen block is skipped through VMALLFROZEN, and an all-open bit is automatically marked. According to the method, full-table scanning overhead is reduced, I / O and CPU occupation is reduced, online smooth upgrading is supported, long-term performance and operation and maintenance convenience of the database are improved, and compatibility of new and old versions and system stability are guaranteed.

Description

Technical Field

[0001] This application relates to the field of database operation technology, and in particular to a method, apparatus, computer-readable storage medium, and electronic device for progressive visibility mapping upgrade and freeze optimization of a database. Background Technology

[0002] The incremental nature of database transaction IDs (TXIDs) limits their numerical space to a theoretical upper limit. With the continuous expansion of data scale and the long-term operation of business systems, the freeze operation in transaction ID wraparound mechanisms has become a key bottleneck affecting the stability and performance of modern database systems. Traditional visibility map (VM) mechanisms only record the page-level visibility state of data blocks. When performing vacuumfreeze maintenance, a full table scan of the target table is still required to determine the tuple freeze condition row by row, resulting in repetitive I / O and CPU overhead in petabyte-scale data scenarios. Given the increasingly prominent issue of freeze efficiency limitations, how to achieve lightweight and performance-enhanced freeze operations while ensuring data consistency has become a key research direction in the field of database kernel optimization.

[0003] Existing freeze optimization solutions generally rely on extending the visibility mapping structure, adding block-level freeze flags (all-frozen) to eliminate unnecessary tuple scans. However, such solutions have significant limitations in engineering practice: for example, VM structure upgrades typically require database instance downtime for maintenance and force a one-time rewrite of the metadata format of all database data blocks, resulting in long business interruption windows, high upgrade risks, and soaring operational costs. Furthermore, enterprise-level deployments often require accompanying freeze window policy management, performance baseline monitoring, and manual intervention contingency plans, exacerbating system complexity and operational burden. Therefore, building a progressive freeze optimization mechanism that supports online, on-demand, and phased implementation has significant engineering application value for ensuring business continuity and reducing migration risks. Summary of the Invention

[0004] To overcome the aforementioned shortcomings of existing technologies, this application proposes a novel method for progressive visibility mapping upgrade and freeze optimization of databases.

[0005] The purpose of this invention is to provide a database freeze optimization scheme that can be progressively upgraded without requiring a one-time full table reconstruction. By adding an all-frozen bit in the VM and achieving mixed compatibility between new and old versions, the system can identify, mark and use frozen status information as needed during operation, thereby significantly reducing the full table scan overhead of vacuum freeze operations, significantly reducing system I / O overhead and CPU utilization, and improving the long-term operating performance and maintenance convenience of the database.

[0006] In summary, this solution designs a visibility mapping extension structure with bidirectional compatibility. While retaining existing VM semantics, it adds an all-frozen flag and constructs version-aware I / O and parsing logic, thereby enabling on-demand upgrades and transparent, incremental deployment of freeze optimization. During continuous system operation, operations personnel can upgrade data blocks to the new format in batches according to tablespaces and business priorities without interrupting external services. This smooth evolution mechanism ensures the gradual accumulation of optimization benefits while substantially reducing the threshold and operational risks of end-to-end upgrades, providing a quantifiable, rollbackable, and monitorable lightweight freeze optimization path for the long-term stable operation of database systems.

[0007] Specifically, this application provides the following technical solutions: The first aspect of this application provides a method for progressive visibility mapping upgrade and freeze optimization of a database, the method comprising: S1. Version tag: Add the PD_VM_FROZEN flag to the metadata header of the VM (Visibility Mapping) block to indicate whether the VM is a new version that includes the all-frozen bit; S2. Version Identification and Adaptation: Add a vm_version field to the Relation memory structure of the table to record the VM version status. The VM version status includes VM_VERSION_VISIBLE, VM_VERSION_FROZEN and VM_VERSION_UNKNOWN. The VM version is dynamically detected by the visibilitymap_get_version method. S3. Interface unification and extension: Modify VM-related interfaces to support dynamic calculation of block position and bit width based on version. Add the VM_ALL_FROZEN macro to check whether all blocks are frozen. Older VM versions will automatically return false when calling it. S4. Progressive version upgrade: Newly created VMs are automatically marked as new versions. Old version VMs are only progressively upgraded to new versions when the table performs VACUUM FULL, TRUNCATE, or pg.repack operations. Existing VMs retain their current versions when expanding VM blocks. S5. VACUUM Process Management: In aggressive mode, frozen blocks are skipped via the VM_ALL_FROZEN interface. New frozen blocks are automatically marked as all-frozen during the scan, and the skipping behavior can be controlled via the DISABLE_PAGE_SKIPPING option.

[0008] Furthermore, in the method of this application, the PD_VM_FROZEN flag bit mentioned in step S1 is located in the pageHeader header of the VM block, which is used to distinguish between the new version VM block containing the freeze flag and the old version VM block containing only the visibility flag. The VM version is determined by reading this flag bit, and the new and old versions of VM coexist in the same database.

[0009] Furthermore, in the method of this application, the vm_version field mentioned in step S2 is cached in the Relation structure, and is automatically initialized by reading the PD_VM_FROZEN flag bit of the 0th block of the VM file when the VM is accessed for the first time.

[0010] Furthermore, in the method of this application, step S2 also includes: based on the VM version type obtained by dynamic detection, adaptively performing VM block addressing, expansion and resolution operations, so that VM blocks of different versions can be mixed and accessed in the same database instance without interfering with each other.

[0011] Furthermore, in the method of this application, the implementation logic of the VM_ALL_FROZEN macro in step S3 is as follows: if the VM version is VM_VERSION_FROZEN and the all-frozen bit of the corresponding block is 1, then return true; otherwise, return false.

[0012] Furthermore, in the method of this application, step S5 also includes a freeze check optimization step, specifically including: Non-freeze mode: Only check the all-visible bits; if all tuples in the block are visible, skip the scan. Freeze mode: Only checks all-frozen bits; if all tuples in the block are frozen, the scan and freeze check are skipped. After the scan is complete, if all tuples in the block are marked as frozen and the VM version is VM_VERSION_FROZEN, then set the all-frozen bit for that block.

[0013] A second aspect of this application provides a progressive visibility mapping upgrade and freeze optimization apparatus for a database. The apparatus, when operating, implements the steps of the aforementioned progressive visibility mapping upgrade and freeze optimization method for a database. The apparatus includes: The version tagging module is used to add the PD_VM_FROZEN flag bit to the metadata header of the VM block to identify whether the VM is a new version containing the all-frozen bit; The version identification module is used to add a vm_version field to the Relation memory structure of the table to record the VM version status, which includes VM_VERSION_VISIBLE, VM_VERSION_FROZEN and VM_VERSION_UNKNOWN, and dynamically detect the VM version through the visibilitymap_get_version method. The interface adaptation module is used to modify VM-related interfaces to enable them to dynamically calculate block position and bit width based on the version. A new VM_ALL_FROZEN macro is added to check whether all blocks are frozen. When older versions of VM call this, it will automatically return false. The version upgrade module is used to automatically mark newly created VMs as the new version. Old version VMs are only upgraded to the new version when the table performs VACUUM FULL, TRUNCATE or pg.repack operations. Existing VMs retain their existing version when expanding VM blocks. Freeze optimization module: Integrated into the VACUUM process, it is used to skip frozen blocks in aggressive mode via the VM_ALL_FROZEN interface, automatically mark new frozen blocks as all-frozen during the scan, and supports controlling the skipping behavior through the DISABLE_PAGE_SKIPPING option.

[0014] Furthermore, in the device of this application, the freeze optimization module includes: Freeze marking unit: During the scanning process, blocks that meet the freezing conditions are marked as all-frozen; Skip Control Unit: Disable the freeze block skip function via the DISABLE_PAGE_SKIPPING option for debugging or forced scene scanning.

[0015] A third aspect of this application provides an electronic device, including: a memory and a processor; Memory: Used to store computer programs; Processor: Used to execute the computer program to implement the steps of the aforementioned progressive visibility mapping upgrade and freeze optimization method for the database.

[0016] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the steps of the aforementioned progressive visibility mapping upgrade and freeze optimization method for a database.

[0017] In summary, this invention achieves the following technical effects through a progressive visibility mapping (VM) upgrade mechanism (adding an all-frozen bit and ensuring compatibility between new and old versions) and on-demand freeze state identification logic: (1) By designing version tag (PD_VM_FROZEN), dynamic adaptation interface and progressive upgrade path (trigger-based on-demand migration), the bottleneck of traditional solution's full table scan dependency and downtime upgrade is broken.

[0018] (2) Significantly reduces the overhead of full table scans via vacuum freeze (reduces I / O and CPU usage), supports smooth online evolution (zero downtime upgrades), improves the long-term performance and ease of operation and maintenance of the database, and ensures transaction consistency and version compatibility.

[0019] (3) By modifying the kernel to be lightweight, the efficiency of freezing, system availability and operation and maintenance costs are balanced, providing a sustainable optimization path for massive data scenarios.

[0020] Other features and advantages of this application will be set forth in detail in the following description, or will become apparent through the implementation of the relevant technical solutions of this application. The objectives and other advantages of this application can be achieved through the technical features and means explicitly pointed out in the description, claims, and drawings, and will be obtained through the implementation of these technical contents. Attached Figure Description

[0021] To more clearly illustrate the technical solution of the present invention, the accompanying drawings involved in the description of the present invention will be briefly introduced below. It should be noted that the drawings only show some embodiments of the present invention. For those skilled in the art, other related drawings can be derived from these drawings without creative effort.

[0022] Figure 1 This is a comparison diagram of the structure of the VM internal block before and after the upgrade in the embodiment of this application.

[0023] Figure 2 This is a flowchart illustrating the use of VM in the embodiments of this application.

[0024] Figure 3 This is a flowchart illustrating the overall implementation process of the progressive visibility mapping upgrade and freeze optimization method for the database in this application.

[0025] Figure 4 This is a structural diagram of the progressive visibility mapping upgrade and freeze optimization device for the database in this application.

[0026] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be noted that the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0028] In this document, the term "comprising" and any variations thereof (such as "including," "including," etc.) are open-ended expressions and should be understood as "including but not limited to," meaning that the listed content is not exhaustive and may include other content not explicitly mentioned. The term "based on" should be understood as "at least partially based on," meaning that the basis or condition referred to may not be the only factor and may involve other relevant factors. The term "one embodiment" should be understood as "at least one embodiment," meaning that the described embodiment is not the only possible implementation, and other similar embodiments may exist.

[0029] In this application, the terms "a" and "a plurality of" are used to modify related elements or features, and their expression is illustrative rather than restrictive. Unless otherwise expressly stated in the context, "a" should be understood as "at least one," and "a plurality of" should be understood as "at least two." Those skilled in the art should reasonably interpret these terms based on the semantic and logical relationships of the context to ensure that they cover the possibility of "one or more."

[0030] Example: A progressive visibility mapping upgrade and freeze optimization method for databases This invention, based on the existing visibility map mechanism, achieves a smooth upgrade and transparent transition for freeze optimization through the following structural modifications and process controls: Version marking mechanism: A new flag bit PD_VM_FROZEN is added to the general header (pageHeader) of the VM block to identify whether the VM is a new version (including the all-frozen bit). The system automatically identifies the VM version by reading this flag bit. New and old versions of VMs can coexist in the database, and there is no requirement to upgrade all tables at once and block database usage.

[0031] Version identification and adaptation: vm_version information is added to the Relation memory structure of the table, supporting three states: VM_VERSION_UNKNOWN, VM_VERSION_VISIBLE (only including the all-visible bit), and VM_VERSION_FROZEN (including both all-visible and all-frozen bits). When the system accesses a VM for the first time, the version is automatically detected and recorded using the visibilitymap_get_version method. Subsequent operations select the corresponding interface logic based on the version, achieving compatibility between new and old VMs.

[0032] Interface unification and extension: Modify VM-related interfaces to support dynamic calculation of block position and bit width based on version. Add the VM_ALL_FROZEN macro to check whether all blocks are frozen; older VM versions will automatically return false when called to ensure consistent interface behavior.

[0033] A gradual upgrade path: Newly created or expanded VM blocks are automatically marked as the new version; older version VMs are only gradually upgraded to the new version when the table visibility map is cleared (e.g., by VACUUM FULL, TRUNCATE, pg_repack operations), without requiring system downtime or a one-time full table migration. The system continuously accumulates all-frozen status information during operation, gradually improving freeze skipping efficiency.

[0034] VACUUM workflow integration: In aggressive mode, VACUUM skips frozen blocks through the VM_ALL_FROZEN interface; during the scan, new frozen blocks are automatically marked as all-frozen, and the skipping behavior can be flexibly controlled through the DISABLE_PAGE_SKIPPING option, taking into account both optimization effects and debugging needs.

[0035] Through the above solution, the system can achieve continuous accumulation of freeze optimization effects while maintaining backward compatibility, significantly reducing repetitive maintenance overhead and improving database operation and maintenance efficiency and system stability.

[0036] To more clearly illustrate the technical solution of this application, the following will take the openGauss database as an example and provide further explanation through specific scenario implementations.

[0037] First, let's introduce the relevant technical background of the openGauss database: openGauss's Vacuum and freeze mechanisms: To clean up invalid tuples (dead tuples) and prevent transaction ID wrap-around, the database needs to periodically perform VACUUM operations. The freeze operation is responsible for marking outdated transaction IDs as "frozen," making them visible to all transactions. Traditional processes require scanning all table blocks to check for tuple freeze status, resulting in significant overhead.

[0038] Visibility Map (VM): A bitmap structure used to quickly mark which data blocks all tuples are "visible" to all transactions. Traditional VMs only contain all-visible bits, used to speed up the cleanup of dead tuples in VACUUM, but cannot skip freeze scans. The new VM in this solution includes both all-visible and all-frozen bits; during freeze scans, the all-frozen bits can be used to skip parts of the scan (e.g., ...). Figure 1 (As shown).

[0039] Relation structure in memory: In the database memory, each open table corresponds to a Relation structure, which is used to cache the table's metadata, file handles, etc.

[0040] This embodiment describes a method for optimizing the freeze operation by progressively expanding the VM structure in the database kernel.

[0041] When the database executes the freeze command on a table, the database kernel uses the VM in the following process: 1. Initialize the Relation structure corresponding to the table, where the vm_version field is initialized to VM_VERSION_UNKNOWN.

[0042] 2. Retrieve the VM version corresponding to the table (corresponding to) Figure 2 in visibilitymap_get_version): (1) Call the visibilitymap_get_version method to read the 0th block of the VM file of the table.

[0043] (2) Check whether the block header pageHeader contains the PD_VM_FROZEN flag.

[0044] (3) Based on the flag, set the Relation's vm_version to VM_VERSION_VISIBLE (old version) or VM_VERSION_FROZEN (new version). If no VM file exists, the new version will be used. This version information is cached throughout the Relation's lifecycle to avoid duplicate checks.

[0045] 3. Read the VM block corresponding to the table block (corresponding to) Figure 2 (vm_extend) (1) Read the VM information location corresponding to the table block. Calculate the corresponding VM block number based on the table block number.

[0046] (2) If the VM does not have the required blocks, the VM is extended. Each extended block needs to determine whether to mark the new block's pageHeader and whether to mark PD_VM_FROZEN based on the current VM version.

[0047] (3) Read the all-visible bit and all-frozen bit information of the table block.

[0048] 4. Scan the table and apply optimizations. For each table block, call different VM interfaces based on the VACUUM mode: (1) Check if the scan of the table block can be skipped. Non-freeze mode: check the all-visible bit. If all the data in the block is visible, skip the tuple scan of the block. Freeze mode: check the all-frozen bit. If the block is marked as fully frozen, skip the scan and freeze check of the block.

[0049] (2) If the block is not skipped, scan all the tuples in it and determine whether each tuple needs to be frozen.

[0050] (3) After the scan is completed, if all tuples in the block are "visible" and "frozen", and the VM version is new, then set the all-frozen bit of the corresponding VM block.

[0051] Throughout the process, all VM operations (read, set, clean) automatically adapt to the old and new versions using vm_version. When a table is rebuilt due to VACUUM FULL, TRUNCATE, or pg_repack operations, its VM file will be created and automatically adopt the new format, thus achieving a gradual, on-demand upgrade of the old version VM without having to convert all tables at once.

[0052] Figure 3 The diagram shows the overall implementation flow of the progressive visibility mapping upgrade and freeze optimization method for the database provided in this application, including the following steps: S1. Version tag: Add the PD_VM_FROZEN flag to the metadata header of the VM (Visibility Mapping) block to indicate whether the VM is a new version that includes the all-frozen bit; S2. Version Identification and Adaptation: Add a vm_version field to the Relation memory structure of the table to record the VM version status. The VM version status includes VM_VERSION_VISIBLE, VM_VERSION_FROZEN and VM_VERSION_UNKNOWN. The VM version is dynamically detected by the visibilitymap_get_version method. S3. Interface unification and extension: Modify VM-related interfaces to support dynamic calculation of block position and bit width based on version. Add the VM_ALL_FROZEN macro to check whether all blocks are frozen. When older versions of VM call this macro, it will automatically return false. S4. Progressive version upgrade: Newly created VMs are automatically marked as new versions. Old version VMs are only progressively upgraded to new versions when the table performs VACUUM FULL, TRUNCATE, or pg.repack operations. Existing VMs retain their current versions when expanding VM blocks. S5. VACUUM Process Management: In aggressive mode, frozen blocks are skipped via the VM_ALL_FROZEN interface. New frozen blocks are automatically marked as all-frozen during the scan, and the skipping behavior can be controlled via the DISABLE_PAGE_SKIPPING option.

[0053] Figure 4 The diagram shows a progressive visibility mapping upgrade and freeze optimization apparatus for a database according to this application. The apparatus, when running, implements the steps of the aforementioned progressive visibility mapping upgrade and freeze optimization method for a database. The apparatus includes: The version tagging module is used to add the PD_VM_FROZEN flag bit to the metadata header of the VM block to identify whether the VM is a new version containing the all-frozen bit; The version identification module is used to add a vm_version field to the Relation memory structure of the table to record the VM version status, which includes VM_VERSION_VISIBLE, VM_VERSION_FROZEN and VM_VERSION_UNKNOWN, and dynamically detect the VM version through the visibilitymap_get_version method. The interface adaptation module is used to modify VM-related interfaces to enable them to dynamically calculate block position and bit width based on the version. A new VM_ALL_FROZEN macro is added to check whether all blocks are frozen. When older versions of VM call this, it will automatically return false. The version upgrade module is used to automatically mark newly created VMs as the new version. Old version VMs are only upgraded to the new version when the table performs VACUUM FULL, TRUNCATE or pg.repack operations. Existing VMs retain their existing version when expanding VM blocks. Freeze optimization module: Integrated into the VACUUM process, it is used to skip frozen blocks in aggressive mode via the VM_ALL_FROZEN interface, automatically mark new frozen blocks as all-frozen during the scan, and supports controlling the skipping behavior through the DISABLE_PAGE_SKIPPING option.

[0054] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of apparatus, methods, and computer program products according to various embodiments of this application, including architecture, functionality, and operation. In these figures, each block may represent a module, program segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should be noted that each block in the block diagrams and / or flowcharts, and combinations thereof, can be implemented using either a dedicated hardware-based system or a combination of dedicated hardware and computer instructions to achieve the specified function or operation.

[0055] like Figure 5 As shown, embodiments of this application also disclose an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing processor-executable computer programs, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 executes the executable computer program to implement the steps of the aforementioned progressive visibility mapping upgrade and freeze optimization method for databases.

[0056] It is understood that, in addition to memory and a processor, this electronic device may also include input devices (such as a keyboard), output devices (such as a display), and other communication modules. These input devices, output devices, and other communication modules all communicate with the processor through I / O interfaces (i.e., input / output interfaces).

[0057] The operations described in this application can be implemented by writing computer program code using one or more programming languages ​​or a combination thereof. The programming languages ​​include, but are not limited to, the following types: Object-oriented programming languages, such as Java, Smalltalk, C++, etc. Conventional procedural programming languages, such as "C" or similar programming languages.

[0058] The execution methods of program code include, but are not limited to: It runs entirely on the user's computer; Part of it executes on the user's computer, and part of it executes on a remote computer; Execute as a standalone software package; It is executed entirely on a remote computer or server.

[0059] In scenarios involving remote computers, the remote computer can connect to the user's computer via any type of network, including but not limited to local area networks (LANs) or wide area networks (WANs). Furthermore, the remote computer can also connect to external computers via an internet service provider, for example, by utilizing the internet.

[0060] Furthermore, this application also discloses a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the various steps of the progressive visibility mapping upgrade and freeze optimization method for the database disclosed in this application.

[0061] In the context of this application, a computer-readable storage medium refers to a tangible medium capable of storing computer program code and related data. Specific examples include, but are not limited to, the following: (1) Portable computer disk: such as floppy disks and other removable magnetic storage media.

[0062] (2) Hard disk: including mechanical hard disks and solid-state hard disks and other fixed storage devices.

[0063] (3) Random Access Memory (RAM): A volatile storage medium used for temporary storage of data and program code.

[0064] (4) Read-only memory (ROM): a non-volatile storage medium used to store fixed programs and data.

[0065] (5) Erasable programmable read-only memory (EPROM) or flash memory: non-volatile storage media that supports multiple erasures and reprogrammings.

[0066] (6) Fiber optic storage devices: storage media based on fiber optic technology.

[0067] (7) Portable compact disc read-only memory (CD-ROM): a read-only medium that stores data in the form of an optical disc.

[0068] (8) Optical storage devices: such as DVDs, Blu-ray discs and other storage media based on optical principles.

[0069] (9) Magnetic storage devices: such as magnetic tapes, disks and other storage media based on magnetic principles.

[0070] (10) Any suitable combination of the above: for example, combining multiple storage media to meet different storage needs.

[0071] These computer-readable storage media can be used to store the program code and related data described in this application to support program execution and persistent data storage.

[0072] Specifically, according to embodiments of this application, the processes described in the flowcharts can be implemented as computer software programs. For example, embodiments of this application relate to a computer program product comprising a computer program carried on a non-transitory computer-readable medium. This computer program includes program code for executing the progressive visibility mapping upgrade and freeze optimization method for the database disclosed in this application. When the computer program is executed by a processing device, it can achieve the functions defined in the embodiments of this application.

[0073] While the foregoing discussion contains several specific implementation details, these details should not be construed as limiting the scope of this application. The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this application is not limited to technical solutions formed by specific combinations of the above-described technical features. Furthermore, this application should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the foregoing disclosed concept.

[0074] Those skilled in the art should also understand that modifications can be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features, without departing from the spirit and scope of the technical solutions of the embodiments of this application. These modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for progressive visibility mapping upgrade and freeze optimization of a database, characterized in that, The method includes: S1. Version tag: Add the PD_VM_FROZEN flag to the metadata header of the VM block to indicate whether the VM is a new version that includes the all-frozen bit; S2. Version Identification and Adaptation: Add a vm_version field to the Relation memory structure of the table to record the VM version status. The VM version status includes VM_VERSION_VISIBLE, VM_VERSION_FROZEN and VM_VERSION_UNKNOWN. The VM version is dynamically detected by the visibilitymap_get_version method. S3. Interface unification and extension: Modify VM-related interfaces to support dynamic calculation of block position and bit width based on version. Add the VM_ALL_FROZEN macro to check whether all blocks are frozen. Older VM versions will automatically return false when calling it. S4. Progressive version upgrade: Newly created VMs are automatically marked as new versions. Old version VMs are only progressively upgraded to new versions when the table performs VACUUMFULL, TRUNCATE, or pg.repack operations. Existing VMs retain their current versions when expanding VM blocks. S5. VACUUM Process Management: In aggressive mode, frozen blocks are skipped via the VM_ALL_FROZEN interface. New frozen blocks are automatically marked as all-frozen during the scan, and the skipping behavior can be controlled via the DISABLE_PAGE_SKIPPING option.

2. The method according to claim 1, characterized in that, The PD_VM_FROZEN flag in step S1 is located in the pageHeader of the VM block. It is used to distinguish between a new version VM block that contains a freeze flag and an old version VM block that only contains a visibility flag. The VM version is determined by reading this flag, and the new and old versions of VM coexist in the same database.

3. The method according to claim 1, characterized in that, The vm_version field mentioned in step S2 is cached in the Relation structure and is automatically initialized when the VM is accessed for the first time by reading the PD_VM_FROZEN flag bit of the 0th block of the VM file.

4. The method according to claim 1, characterized in that, Step S2 also includes: based on the VM version type obtained by dynamic detection, adaptively performing VM block addressing, expansion and resolution operations, so that VM blocks of different versions can be accessed in the same database instance without interfering with each other.

5. The method according to claim 1, characterized in that, The implementation logic of the VM_ALL_FROZEN macro in step S3 is as follows: if the VM version is VM_VERSION_FROZEN and the all-frozen bit of the corresponding block is 1, then return true; otherwise, return false.

6. The method according to claim 1, characterized in that, Step S5 also includes a freeze check optimization step, specifically including: Non-freeze mode: Only check the all-visible bits; if all tuples in the block are visible, skip the scan. Freeze mode: Only checks all-frozen bits; if all tuples in the block are frozen, the scan and freeze check are skipped. After the scan is complete, if all tuples in the block are marked as frozen and the VM version is VM_VERSION_FROZEN, then set the all-frozen bit for that block.

7. A progressive visibility mapping upgrade and freeze optimization device for a database, characterized in that, The apparatus, when in operation, implements the progressive visibility mapping upgrade and freeze optimization method for the database as described in any one of claims 1-6, wherein the apparatus comprises: The version tagging module is used to add the PD_VM_FROZEN flag bit to the metadata header of the VM block to identify whether the VM is a new version containing the all-frozen bit; The version identification module is used to add a vm_version field to the Relation memory structure of the table to record the VM version status, which includes VM_VERSION_VISIBLE, VM_VERSION_FROZEN and VM_VERSION_UNKNOWN, and dynamically detect the VM version through the visibilitymap_get_version method. The interface adaptation module is used to modify VM-related interfaces to enable them to dynamically calculate block position and bit width based on the version. A new VM_ALL_FROZEN macro is added to check whether all blocks are frozen. When older versions of VM call this, it will automatically return false. The version upgrade module is used to automatically mark newly created VMs as the new version. Old version VMs are only upgraded to the new version when the table performs VACUUMFULL, TRUNCATE or pg.repack operations. Existing VMs retain their existing version when expanding VM blocks. Freeze optimization module: Integrated into the VACUUM process, it is used to skip frozen blocks in aggressive mode via the VM_ALL_FROZEN interface, automatically mark new frozen blocks as all-frozen during the scan, and supports controlling the skipping behavior through the DISABLE_PAGE_SKIPPING option.

8. The apparatus according to claim 7, characterized in that, The freeze optimization module includes: Freeze marking unit: During the scanning process, blocks that meet the freezing conditions are marked as all-frozen; Skip Control Unit: Disable the freeze block skip function via the DISABLE_PAGE_SKIPPING option for debugging or forced scene scanning.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the progressive visibility mapping upgrade and freeze optimization method for the database as described in any one of claims 1-6.

10. An electronic device, characterized in that, include: Memory and processor; Memory: Used to store computer programs; Processor: for executing the computer program to implement the steps of the progressive visibility mapping upgrade and freeze optimization method for the database as described in any one of claims 1-6.

Images