如何最大限度地减少Postgresql查询中CTE的使用

如何最大限度地减少Postgresql查询中CTE的使用,postgresql,optimization,common-table-expression,with-statement,Postgresql,Optimization,Common Table Expression,With Statement,下面的代码适用于少量向量特征。但是,当我使用较大的表(约35000行)运行查询时,我的内存使用率将达到100%(32GB),然后在pgadmin中获得“与服务器的连接已丢失”。我在本地主机上运行,因此问题与网络无关。我猜是因为我习惯了很多CTE(带查询)。我正在考虑将查询嵌套在PL/pgSQL循环中,并用结果更新表。从而在每次迭代后关闭临时表。这似乎是一个不雅观的解决方案,我希望有人能告诉我如何在下面的查询中最小化CTE的使用 CREATE TABLE dem_stats AS WITH --

下面的代码适用于少量向量特征。但是,当我使用较大的表(约35000行)运行查询时,我的内存使用率将达到100%(32GB),然后在pgadmin中获得“与服务器的连接已丢失”。我在本地主机上运行,因此问题与网络无关。我猜是因为我习惯了很多CTE(带查询)。我正在考虑将查询嵌套在PL/pgSQL循环中,并用结果更新表。从而在每次迭代后关闭临时表。这似乎是一个不雅观的解决方案,我希望有人能告诉我如何在下面的查询中最小化CTE的使用

CREATE TABLE dem_stats AS
WITH
--  Select Features using lookup table and determine the raster tiles said features are intersecting
    feat AS 
        (SELECT title_no,
                a.grid_tile_name || '.asc' AS tile_name,
                a.wkb_geometry as geom
                FROM test_polygons a, parcels_all_shapefile_lookup_osgb_grid_5km b
                    WHERE a.title_no = b.olp_title_no
        ),
-- Merge rasters tiles from main raster file that intersect features        
    merged_rast AS
        (SELECT ST_Union(rast,1) AS rast
            FROM dem, feat
                WHERE filename
                    IN (tile_name)
        ),
-- As the tiles are now merged duplicates are not required
    feat_temp AS 
        (SELECT DISTINCT ON (title_no) * FROM feat
        ),
-- Clip merged raster and obtain pixel statistics
    b_stats AS
        (SELECT title_no, (stats).*
            FROM (SELECT title_no, ST_SummaryStats(ST_Clip(a.rast,1,b.geom,-9999,true)) AS stats
                FROM merged_rast a
                    INNER JOIN feat_temp b
                ON ST_Intersects(b.geom,a.rast)
            ) AS foo
        )
--  Summarise statistics for each title number
    SELECT title_no,
           count As pixel_val_count,
           min AS pixel_val_min,
           max AS pixel_val_max,
           mean AS pixel_val_mean,
           stddev AS pixel_val_stddev
            FROM b_stats
                WHERE count > 0;

虽然它不完全可读,但您可以始终内联CTE-这有时是个好主意,因为CTE是PostgreSQL中的优化屏障: