0

我的数据库中有一个 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 的返回效果非常好，但这是一个（或多个）无法正常工作的站点。有什么建议么？

PS <->运算符的使用来自pg_trgm模块。

4

1 回答 1

1

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

  1. 将您的故障排除分为几个步骤。从最简单的查询开始。没有聚合，只有连接，没有过滤器。然后添加过滤器。然后添加 order by，然后添加聚合。看看发生变化的确切位置。

  2. 尝试重新索引数据库。

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

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

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

第二种可能是过滤语句的连接条件有错字。通常这是我首先会怀疑的事情，但是从那里开始清除索引问题很容易。如果删除 ORDER BY 不会改变事情，那么很可能是一个错字。如果找不到错字，请尝试重新索引。

于 2013-11-26T04:11:40.000 回答