Question

我的数据库中有一个UDF，它基本上试图根据一些输入数据（地理/名称/类型）获得一个站（例如公共汽车/火车）。在这个函数里面，我试着检查是否有任何符合给定值的行：

SELECT 
    COUNT(s.id) 
INTO 
    firsttry 
FROM 
    geographic.stations AS s
WHERE 
    ST_DWithin(s.the_geom,plocation,0.0017) 
AND 
    s.name <-> pname < 0.8 
AND 
    s.type ~ stype;

firsttry 变量现在包含值1.如果我使用以下（略微扩展的）SELECT语句，我得不到结果：

RETURN query SELECT
        s.id, s.name, s.type, s.the_geom,
        similarity(
            regexp_replace(s.name::text,'(Hauptbahnhof|Hbf)','Hbf'),
            regexp_replace(pname::text,'(Hauptbahnhof|Hbf)','Hbf')
        )::double precision AS sml,
        st_distance(s.the_geom,plocation) As dist from geographic.stations AS s
    WHERE ST_DWithin(s.the_geom,plocation,0.0017) and s.name <-> pname < 0.8 
    AND s.type ~ stype
    ORDER BY dist asc,sml desc LIMIT 1;

参数如下：

stype = '^railway'
pname = 'Amsterdam Science Park'
plocation = ST_GeomFromEWKT('SRID=4326;POINT(4.9492530 52.3531670)')

我需要返回的元组是：

id     name                    type              geom (displayed as ST_AsText)
909658;"Amsterdam Sciencepark";"railway_station";"POINT(4.9482893 52.352904)"

同样的UDF对于很多其他站点来说返回得很好，但这是一个（更多），这是不行的。有什么建议？

P.S。使用＆lt; - ＆gt; 运算符来自pg_trgm模块。

Answer 1

关于如何解决此问题的一些想法：

将您的问题排查分解为步骤。从最简单的查询开始。没有聚合，只是加入，没有过滤器。然后添加过滤器。然后添加order by，然后添加聚合。仔细查看发生变化的位置。
尝试重新编制数据库索引。

基于此，我发生的一种可能性是它可能是第二个查询中使用的损坏索引，但不是第一个查询中使用的。我在过去看到过损坏的索引，通常它们会抛出错误，但至少在理论上它们应该能够创建这样的问题。

如果这是正确的，如果删除ORDER BY子句，查询将突然返回行。

如果索引已损坏，则需要密切关注硬件。是RAM ECC吗？处理器是否过热？你的磁盘怎么样？

第二种可能性是filter语句的连接条件存在拼写错误。通常情况下，这是我首先要怀疑的东西，但是很容易将索引问题排除在外。如果删除ORDER BY不会改变事情，那么很可能是一个错字。如果找不到拼写错误，请尝试重新编制索引。

COUNT（字段）返回正确的行数，但完整的SELECT查询返回零行

1 个答案: