A tensor query execution optimization method, system, device and medium for a GPU resource limited scene
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- RENMIN UNIVERSITY OF CHINA
- Filing Date
- 2026-03-13
- Publication Date
- 2026-06-26
Smart Images
Figure CN122285701A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer systems and database technology, and in particular to a method, system, device and medium for optimizing tensor query execution in GPU resource-constrained environments, applicable to big data analysis and complex SQL query processing scenarios. Background Technology
[0002] In recent years, database systems have begun to leverage tensor computing frameworks to represent relational data as tensors and accelerate SQL query execution through GPU parallel computing. Due to the high bandwidth and massive parallelism of GPUs, tensor operators can significantly accelerate operations such as filtering, joining, and aggregation. However, the on-chip memory capacity of GPUs is typically much smaller than that of CPU memory, and tensor execution often generates a large number of intermediate tensors, making peak memory usage a key bottleneck for performance and availability.
[0003] In resource-constrained scenarios, traditional GPU-accelerated database systems typically employ fixed-block or simple batch processing to reduce the size of a single working set. However, such strategies struggle to explicitly characterize the amplification effect of different operators on intermediate results. When encountering operators such as sorting, grouping aggregation, and string predicates, intermediate results may expand rapidly, leading to memory overflow or forcing the adoption of overly conservative batch settings, thereby significantly reducing throughput.
[0004] On the other hand, heterogeneous CPU-GPU collaborative execution can take advantage of the CPU's large memory capacity and the GPU's parallel computing advantage. However, existing solutions often lack an interpretable scheduling mechanism under memory constraints, which can easily lead to problems such as excessive cross-device data transfer overhead, unreasonable execution phase segmentation, and the introduction of additional memory pressure to hide data transfer.
[0005] Furthermore, analytical queries containing string predicates (such as LIKE, IN, etc.) are typically inefficient on GPUs: on the one hand, string matching is difficult to fully vectorize; on the other hand, directly transferring strings to the GPU in their raw form and scanning them would incur memory and bandwidth overhead. Therefore, a low-overhead, maintainable string filtering structure is needed to accelerate string predicates in resource-constrained scenarios.
[0006] In summary, there is an urgent need for a tensor query optimization scheme that can be stably executed in GPU resource-constrained scenarios. This scheme should use peak video memory as an explicit constraint, combine operator characteristics for batch partitioning and heterogeneous scheduling, and improve throughput and robustness while ensuring query correctness. Summary of the Invention
[0007] To address the aforementioned issues, the present invention aims to provide a method, system, device, and medium for optimizing tensor query execution in GPU resource-constrained scenarios, thereby dynamically controlling peak GPU memory usage and improving query throughput, while providing a low-overhead acceleration structure for string predicates.
[0008] To achieve the above objectives, the present invention adopts the following technical solution:
[0009] In a first aspect, the present invention provides a tensor query execution optimization method for GPU resource-constrained scenarios, comprising: Receive and parse the input SQL query request, and generate a query execution plan based on tensor computation; The operators in the query execution plan are analyzed and evaluated, and the batch granularity and intermediate result format are dynamically determined based on the intermediate result amplification characteristics of the operators and the GPU memory budget. Based on the defined batch granularity and intermediate result format, an operator-aware memory-controlled batch processing strategy is adopted to split the query execution plan into several batches and perform tensor operations on the GPU sequentially. Based on the heterogeneous CPU-GPU collaborative scheduling mechanism, execution is divided between the CPU and GPU sides according to operators or operation stages, and partial results generated by each batch are merged to obtain the final query result and output it.
[0010] Furthermore, when the received SQL query request is a query containing string predicates, a multi-granularity hash string representation is constructed and maintained. During query execution, a candidate set is obtained through hash filtering, and then precise matching is performed to complete the string predicate calculation.
[0011] Furthermore, the analysis and evaluation of operators in the query execution plan, and the dynamic determination of batch granularity and intermediate result format based on the intermediate result amplification characteristics of operators and GPU memory budget, includes: The operators in the query execution plan are categorized based on input size, selectivity, or cardinality estimation. Based on the amplification characteristics of the intermediate results of each operator, the video memory budget of each operator is estimated and used as the peak video memory constraint. The batch granularity of input data is dynamically determined based on the video memory budget and operator type, and the intermediate result format of each batch is also determined.
[0012] Furthermore, the classification of operators in the query execution plan based on input size, selectivity, or cardinality estimation includes: The amplification factor for each operator is determined based on the input size, selectivity, cardinality estimation, or sampling of the input data. ; Based on the amplification factor of each operator, operators are divided into three categories: Data reduction operators; : Data size immutable operators; : Data augmentation operators.
[0013] Furthermore, the step of dynamically determining the batch granularity of input data based on memory budget and operator type, and determining the intermediate result format for each batch, includes: For data augmentation operators, a strategy of "partial computation on GPU + global merging on CPU" is adopted: when the operator contains sub-stages that can be efficiently executed on the GPU, local computation is performed on the GPU to generate compact intermediate results, and the compact intermediate results are transferred to the CPU for merging, global aggregation or global sorting at the stage that requires a global view; when the GPU cannot efficiently process any sub-stage of the operator, or when the current video memory is extremely tight, all sub-stages of the operator are offloaded to the CPU. For data reduction operators or data size invariant operators, they are executed in batches directly on the GPU.
[0014] Furthermore, based on the determined batch granularity and intermediate result format, the operator-aware memory-controlled batch processing strategy is used to split the query execution plan into several batches and perform tensor operations sequentially on the GPU, including: For the current batch, a preset fixed buffer is used on the GPU to carry the temporary intermediate tensor obtained from the tensor operation of the current batch; After the tensor operations of the current batch are completed, temporary intermediate tensors that are no longer needed are released as early as possible based on the execution dependencies, while ensuring the correctness of subsequent stages, for use in the tensor operations of the next batch, so as to avoid the accumulation across batches and the resulting increase in peak memory usage.
[0015] Furthermore, the heterogeneous CPU-GPU collaborative scheduling mechanism divides execution between the CPU and GPU sides according to operators or computation stages, merges partial results generated in each batch, and outputs the final query result, including: Establish a lightweight cost model to estimate the GPU computation time, CPU computation time, CPU-GPU transfer time, and merging time for each operator or operator stage. Based on GPU computation time, CPU computation time, CPU-GPU transfer time, and merging time, select the execution device and pipelined overlap window size for the current operator or operator stage, while satisfying the GPU memory budget.
[0016] Secondly, the present invention provides a tensor query execution optimization system for GPU resource-constrained scenarios, comprising: The query analysis and plan generation module is used to receive and parse the input SQL query requests and generate a query execution plan based on tensor computation. The memory budget and batch partitioning module is used to analyze and evaluate the operators in the query execution plan, and dynamically determine the batch granularity and intermediate result format based on the intermediate result amplification characteristics of the operators and the GPU memory budget. The batch execution and memory management module is used to split the query execution plan into several batches and perform tensor operations on the GPU sequentially, based on a defined batch granularity and intermediate result format, using an operator-aware memory-controlled batch processing strategy. The heterogeneous scheduling and result merging module is used to divide the execution between the CPU and GPU sides according to the operator or operation stage based on the heterogeneous CPU-GPU collaborative scheduling mechanism, and merge the partial results generated by each batch to obtain the final query result and output it.
[0017] Thirdly, the present invention provides a computer-readable storage medium for storing one or more programs, said one or more programs including instructions that, when executed by a computing device, cause the computing device to perform any method.
[0018] Fourthly, the present invention provides a computing device comprising: one or more processors and a memory, wherein the memory stores one or more programs and is configured to be executed by the one or more processors, the one or more programs including instructions for performing any method.
[0019] The present invention has the following advantages due to the adoption of the above technical solutions: 1) This invention uses the peak video memory of the GPU as a first-class constraint. Through operator-aware video memory budget and batch partitioning, it enables stable execution of large-scale analysis queries on video memory-constrained devices, reducing the risk of video memory overflow. 2) This invention reduces temporary storage and redundant allocation overhead and improves resource utilization by using buffer reuse and early release of intermediate tensors; 3) This invention improves overall throughput by using an interpretable heterogeneous CPU-GPU collaborative scheduling and result merging mechanism, which balances computation and relocation overhead while ensuring memory constraints. 4) This invention achieves low-overhead filtering of string predicates through multi-granularity hash string representation, and supports incremental maintenance of insertion, update and deletion, thereby improving the performance of string-related queries.
[0020] Therefore, this invention can be widely applied in the fields of computer systems and database technology. Attached Figure Description
[0021] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. In the drawings: Figure 1 This is a flowchart of a tensor query execution optimization method for GPU resource-constrained scenarios provided in this embodiment of the invention. Detailed Implementation
[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the described embodiments of the present invention are within the scope of protection of the present invention.
[0023] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.
[0024] In some embodiments of the present invention, a tensor query execution optimization method for GPU resource-constrained scenarios is provided, comprising the following steps: receiving and parsing an SQL query to generate a tensor query execution plan; dynamically budgeting the peak GPU memory based on operator characteristics, and accordingly performing operator-aware batch partitioning and query partitioning; reusing buffers and releasing intermediate tensors early during batch execution to keep memory usage under control; employing heterogeneous CPU-GPU collaborative scheduling to divide operators / operator stages at both ends and merge results when memory pressure or operator amplification of intermediate results occurs; and constructing multi-granularity hash representations for string predicates to achieve low-overhead filtering acceleration. This invention can be widely applied to scenarios such as big data analysis and complex SQL query processing.
[0025] Correspondingly, in other embodiments of the present invention, a tensor query execution optimization system, device, and medium for GPU resource-constrained scenarios are provided.
[0026] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the invention and to fully convey the scope of the invention to those skilled in the art.
[0027] Example 1 like Figure 1 As shown, this embodiment provides a tensor query execution optimization method for GPU resource-constrained scenarios, which includes the following steps: 1) Receive and parse the input SQL query request, and generate a query execution plan based on tensor computation; 2) Analyze and evaluate the operators in the query execution plan, and dynamically determine the batch granularity and intermediate result format based on the intermediate result amplification characteristics of the operators and the GPU memory budget; 3) Based on the defined batch granularity and intermediate result format, an operator-aware memory-controlled batch processing strategy is adopted to split the query execution plan into several batches and perform tensor operations on the GPU sequentially. 4) Based on the heterogeneous CPU-GPU collaborative scheduling mechanism, execution is divided between the CPU and GPU sides according to operators or operation stages, and partial results generated by each batch are merged to obtain the final query result and output it.
[0028] Further, in step 1) above, in this embodiment, the specific method for generating a query execution plan based on tensor computation is as follows: receive an SQL query request and perform tensor quantization, generate a query execution plan containing a series of tensor operators, and perform operator-level analysis on the query execution plan, prioritizing the push of column requirements and predicates towards the data source direction to reduce the tensor width and reduce transmission load.
[0029] Furthermore, in step 1) above, when the received SQL query request is a query containing a string predicate, a multi-granularity hash string representation is constructed and maintained. During query execution, a candidate set is obtained through hash filtering, and then precise matching is performed to complete the string predicate calculation.
[0030] Specifically, it includes the following steps: First, queries containing string predicates are hashed at multiple granularities to form columnar arrays or hash tables by hashing the prefixes or substrings. Secondly, when executing the predicate, a hash structure of appropriate granularity is selected for candidate filtering based on the query pattern, and the resulting candidate set is precisely verified to avoid full string scanning.
[0031] For data updates, the new rows are encoded and appended during insertion, while only the affected rows are recalculated and replaced during updates. During deletion, the corresponding rows are masked by validity flags, thus achieving an incrementally maintainable string filtering structure.
[0032] Furthermore, step 2) above includes the following steps: 2.1) Classify the operators in the query execution plan based on input size, selectivity, or cardinality estimation.
[0033] In this embodiment, amplification factors are defined for various operators to serve as amplification features for the intermediate results of each operator. The amplification factor for each operator is defined as follows: =|output| / |input|, based on the scaling factor, all operators are divided into three categories: ① Data reduction operators (such as FILTER and PROJECTION); ② Data-invariant operators (such as SCAN and simple transformations); ③ Data augmentation operators (such as JOIN, GROUP BY, ORDER BY).
[0034] The amplification factor is specifically obtained by estimating it at runtime through static statistics (such as selectivity and connectivity) or by sampling the input data. For operators such as JOIN and FILTER, whose output cardinality is difficult to predict precisely, a conservative scaling factor is used. (Approximately 0.8) to ensure the safety of video memory.
[0035] 2.2) Based on the amplification characteristics of the intermediate results of each operator, the memory budget of each operator is estimated and used as a peak memory constraint to guide the selection of subsequent batch granularity.
[0036] In this embodiment, when estimating the video memory budget, a given operator pipeline is used. and initial batch size Execution up to the The estimated video memory budget after each operation is:
[0037] in, For the first The single-row GPU memory overhead after each step. By constraining... ( As a robustness parameter (approximately 0.8), an upper bound for the safe batch size is derived. This enables safe batch partitioning under memory constraints.
[0038] 2.3) Dynamically determine the batch granularity of input data based on video memory budget and operator type, and determine the intermediate result format of each batch.
[0039] In this embodiment, the operator type determines the intermediate result amplification factor. Different types of operators have different requirements for batch granularity: data reduction operators allow for larger batches; data-invariant operators can be processed at the default granularity; data expansion operators require smaller batches to prevent memory overflow, which is a key factor affecting the choice of batch granularity. By calculating the intermediate results of operators such as filtering, projection, join, aggregation, sorting, and string predicates to amplify features and predicting the size of intermediate tensors, a memory budget is obtained. Then, based on the memory budget, the batch size or partitioning factor is dynamically selected to control the size of single-batch working sets and intermediate tensors, and cross-batch reuse and batch-by-batch eviction are performed between batches.
[0040] Specifically, dynamically determining the intermediate result format for each batch means: For data augmentation operators (such as GROUP BY, ORDER BY, aggregation, etc.), a strategy of "partial computation on GPU + global merging on CPU" is adopted. That is, when the operator contains sub-stages that can be efficiently executed on GPU (such as local aggregation, intra-batch sorting, etc.), local computation is performed on GPU to generate compact intermediate results (such as Boolean masks, partial aggregate values, local sorted sequences, etc.), and the compact intermediate results are transferred to CPU for merging, global aggregation, or global sorting when a global view is required. When GPU cannot efficiently process any sub-stage of the operator, or when the current GPU memory is extremely tight (estimated peak GPU memory exceeds the budget limit), all sub-stages of the operator are offloaded to CPU. For data reduction operators or data size invariant operators (such as filtering, projection, hash join, row-by-row arithmetic calculation, etc.), they are executed directly on the GPU in batch mode.
[0041] This embodiment employs a strategy of "partial computation on the GPU side + global merging on the CPU side," which allows the GPU side to hold only a portion of the results of a single batch, thereby limiting the peak video memory usage to the range of a single batch working set.
[0042] Furthermore, in step 3) above, in this embodiment, when performing tensor operations on the GPU, the overhead of temporary storage and repeated allocation is reduced through buffer reuse and early release of intermediate tensors, so as to improve resource utilization.
[0043] Specifically, it includes the following steps: 3.1) For the current batch, a preset fixed buffer is used on the GPU to carry the temporary intermediate tensors obtained from the tensor operations of the current batch; 3.2) After the tensor operation of the current batch is completed, release the temporary intermediate tensors that are no longer needed as early as possible, based on the execution dependency relationship, while ensuring the correctness of subsequent stages, for use in the tensor operation of the next batch, so as to avoid the accumulation across batches and the resulting increase in peak video memory.
[0044] Furthermore, in step 4) above, performing tensor operations based on the heterogeneous CPU-GPU collaborative scheduling mechanism means: 4.1) Establish a lightweight cost model to estimate the GPU computation time, CPU computation time, CPU-GPU transfer time, and merging time for each operator or operator stage; 4.2) Based on GPU computation time, CPU computation time, CPU-GPU transfer time and merging time, select the execution device and pipelined overlap window size for the current operator or operator stage, while satisfying the GPU memory budget.
[0045] Furthermore, step 4.2 above includes: When memory pressure is high, the pipeline overlap window is reduced or the merging stage is moved to the CPU. The criterion for high memory pressure is comparing the estimated peak GPU memory usage (Mgpu(o)) of the current operator with the memory budget (Mbudget), rather than comparing individual execution times. When Mgpu(o) approaches or exceeds Mbudget (e.g., Mgpu(o) ≥ α·Mbudget, where α is a threshold close to 1, such as 0.9), memory pressure is considered high. In this case, the pipeline overlap window is reduced or the merging stage is moved to the CPU. Execution times (GPU computation time, transfer time, merging time) are used for execution device selection in the cost model, while the memory budget constraint is the primary safety constraint.
[0046] When there is sufficient video memory, data transfer and GPU computation can be overlapped at the batch granularity to hide the transmission overhead.
[0047] In this embodiment, by adopting a heterogeneous CPU-GPU collaborative scheduling and overlapping execution mechanism, robust heterogeneous collaborative execution can be achieved without simultaneously residing multiple batches of data.
[0048] Through the above embodiments, the present invention can stably process large-scale analytical SQL queries in environments with limited GPU memory resources, and achieve better performance and resource efficiency in scenarios containing string predicates.
[0049] Example 2 The above-described embodiment 1 provides a tensor query execution optimization method for GPU resource-constrained scenarios. Correspondingly, this embodiment provides a tensor query execution optimization system for GPU resource-constrained scenarios. The system provided in this embodiment can implement the tensor query execution optimization method for GPU resource-constrained scenarios of embodiment 1. The system can be implemented through software, hardware, or a combination of both. For example, the system may include integrated or separate functional modules or units to execute the corresponding steps in the methods of embodiment 1. Since the system in this embodiment is basically similar to the method embodiment, the description process in this embodiment is relatively simple. Relevant details can be found in the description of embodiment 1. The system embodiment provided in this embodiment is merely illustrative.
[0050] The tensor query execution optimization system provided in this embodiment for GPU resource-constrained scenarios includes: The query analysis and plan generation module is used to receive and parse the input SQL query requests and generate a query execution plan based on tensor computation. The memory budget and batch partitioning module is used to analyze and evaluate the operators in the query execution plan, and dynamically determine the batch granularity and intermediate result format based on the intermediate result amplification characteristics of the operators and the GPU memory budget. The batch execution and memory management module is used to split the query execution plan into several batches and perform tensor operations on the GPU sequentially, based on a defined batch granularity and intermediate result format, using an operator-aware memory-controlled batch processing strategy. The heterogeneous scheduling and result merging module is used to divide the execution between the CPU and GPU sides according to the operator or operation stage based on the heterogeneous CPU-GPU collaborative scheduling mechanism, and merge the partial results generated by each batch to obtain the final query result and output it.
[0051] Example 3 This embodiment provides a processing device corresponding to the tensor query execution optimization method for GPU resource-constrained scenarios provided in Embodiment 1. The processing device can be a client-side processing device, such as a mobile phone, laptop, tablet computer, desktop computer, etc., to execute the method of Embodiment 1.
[0052] The processing device includes a processor, a memory, a communication interface, and a bus. The processor, memory, and communication interface are connected via the bus to enable communication between them. The memory stores a computer program that can run on the processor. When the processor runs the computer program, it executes the tensor query execution optimization method for GPU resource-constrained scenarios provided in Embodiment 1.
[0053] Preferably, the memory may be high-speed random access memory (RAM), and may also include non-volatile memory, such as at least one disk storage device.
[0054] Preferably, the processor can be any type of general-purpose processor such as a central processing unit (CPU) or a digital signal processor (DSP), and there is no limitation herein.
[0055] Example 4 The tensor query execution optimization method for GPU resource-constrained scenarios in Embodiment 1 can be specifically implemented as a computer program product. The computer program product may include a computer-readable storage medium on which computer-readable program instructions for executing the tensor query execution optimization method for GPU resource-constrained scenarios described in Embodiment 1 are loaded.
[0056] A computer-readable storage medium can be a tangible device that holds and stores instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any combination thereof.
[0057] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0058] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0059] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0060] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0061] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.
Claims
1. A method for optimizing tensor query execution in GPU resource-constrained scenarios, characterized in that, include: Receive and parse the input SQL query request, and generate a query execution plan based on tensor computation; The operators in the query execution plan are analyzed and evaluated, and the batch granularity and intermediate result format are dynamically determined based on the intermediate result amplification characteristics of the operators and the GPU memory budget. Based on the defined batch granularity and intermediate result format, an operator-aware memory-controlled batch processing strategy is adopted to split the query execution plan into several batches and perform tensor operations on the GPU sequentially. Based on the heterogeneous CPU-GPU collaborative scheduling mechanism, execution is divided between the CPU and GPU sides according to operators or operation stages, and partial results generated by each batch are merged to obtain the final query result and output it.
2. The tensor query execution optimization method for GPU resource-constrained scenarios as described in claim 1, characterized in that, When the received SQL query request contains a string predicate, a multi-granularity hash string representation is constructed and maintained. During query execution, a candidate set is obtained through hash filtering, and then precise matching is performed to complete the string predicate calculation.
3. The tensor query execution optimization method for GPU resource-constrained scenarios as described in claim 1, characterized in that, The analysis and evaluation of operators in the query execution plan, and the dynamic determination of batch granularity and intermediate result format based on the intermediate result amplification characteristics of operators and GPU memory budget, include: The operators in the query execution plan are categorized based on input size, selectivity, or cardinality estimation. Based on the amplification characteristics of the intermediate results of each operator, the video memory budget of each operator is estimated and used as the peak video memory constraint. The batch granularity of input data is dynamically determined based on the video memory budget and operator type, and the intermediate result format of each batch is also determined.
4. The tensor query execution optimization method for GPU resource-constrained scenarios as described in claim 3, characterized in that, The classification of operators in the query execution plan based on input size, selectivity, or cardinality estimation includes: The amplification factor for each operator is determined based on the input size, selectivity, cardinality estimation, or sampling of the input data. ; Based on the amplification factor of each operator, operators are divided into three categories: Data reduction operators; : Data size immutable operators; : Data augmentation operators.
5. The tensor query execution optimization method for GPU resource-constrained scenarios as described in claim 4, characterized in that, The process of dynamically determining the batch granularity of input data based on memory budget and operator type, and determining the intermediate result format for each batch, includes: For data augmentation operators, a strategy of "partial computation on GPU + global merging on CPU" is adopted: when the operator contains sub-stages that can be efficiently executed on the GPU, local computation is performed on the GPU to generate compact intermediate results, and the compact intermediate results are transferred to the CPU for merging, global aggregation, or global sorting at the stage that requires a global view; when the GPU cannot efficiently process any sub-stage of the operator, or when the current video memory is extremely tight, all sub-stages of the operator are offloaded to the CPU. For data reduction operators or data size invariant operators, they are executed in batches directly on the GPU.
6. The tensor query execution optimization method for GPU resource-constrained scenarios as described in claim 1, characterized in that, Based on a defined batch granularity and intermediate result format, an operator-aware, memory-controlled batch processing strategy is adopted to split the query execution plan into several batches and perform tensor operations sequentially on the GPU, including: For the current batch, a preset fixed buffer is used on the GPU to carry the temporary intermediate tensor obtained from the tensor operation of the current batch; After the tensor operations of the current batch are completed, temporary intermediate tensors that are no longer needed are released as early as possible based on the execution dependencies, while ensuring the correctness of subsequent stages, for use in the tensor operations of the next batch, so as to avoid the accumulation across batches and the resulting increase in peak memory usage.
7. The tensor query execution optimization method for GPU resource-constrained scenarios as described in claim 1, characterized in that, The heterogeneous CPU-GPU collaborative scheduling mechanism divides execution between the CPU and GPU sides according to operators or computation stages, merges partial results generated in each batch, and outputs the final query result, including: Establish a lightweight cost model to estimate the GPU computation time, CPU computation time, CPU-GPU transfer time, and merging time for each operator or operator stage. Based on GPU computation time, CPU computation time, CPU-GPU transfer time, and merging time, select the execution device and pipelined overlap window size for the current operator or operator stage, while satisfying the GPU memory budget.
8. A tensor query execution optimization system for GPU resource-constrained scenarios, characterized in that, include: The query analysis and plan generation module is used to receive and parse the input SQL query requests and generate a query execution plan based on tensor computation. The memory budget and batch partitioning module is used to analyze and evaluate the operators in the query execution plan, and dynamically determine the batch granularity and intermediate result format based on the intermediate result amplification characteristics of the operators and the GPU memory budget. The batch execution and memory management module is used to split the query execution plan into several batches and perform tensor operations on the GPU sequentially, based on a defined batch granularity and intermediate result format, using an operator-aware memory-controlled batch processing strategy. The heterogeneous scheduling and result merging module is used to divide the execution between the CPU and GPU sides according to the operator or operation stage based on the heterogeneous CPU-GPU collaborative scheduling mechanism, and merge the partial results generated by each batch to obtain the final query result and output it.
9. A computer-readable storage medium for storing one or more programs, characterized in that, The one or more programs include instructions that, when executed by a computing device, cause the computing device to perform any of the methods described in claims 1 to 7.
10. A computing device, characterized in that, include: One or more processors and a memory, wherein the memory stores one or more programs and is configured to be executed by the one or more processors, the one or more programs including instructions for performing any of the methods described in claims 1 to 7.