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 回答