Sij*_*tha 1 postgresql postgresql-9.1
我在试图弄清楚为什么查询需要很长时间才能执行时遇到了一些麻烦。当我检查日志时,似乎日志可能不完整。
我的问题是,什么是^M
?我account_invoice
在 Select 语句之前看到了一个相关的错误,它与问题有关吗?
我确定这个陈述是不好的,这需要很多时间,我用 Explain 做了一些研究并发现了这一点。
这是我第一次遇到这个问题,它似乎消耗了很多cpu(cpu负载超过10)。我目前重新启动 postgresql 服务器以使事情恢复工作,这确实不是我将来想要实施的解决方案。任何建议都非常感谢。
[2017-05-31 13:32:26 ICT] app=x db=y user=z command=SELECTSTATEMENT: SELECT province.name,district.name,subdistrict.name,district.icc_ship_area_code^M
FROM province,district,subdistrict,account_invoice,contact^M
WHERE province.id = province_id^M
AND district.id = subdistrict.district_id^M
database=# EXPLAIN SELECT
province.name,district.name,subdistrict.name,district.icc_ship_area_code FROM province,district,subdistrict,account_invoice,contact WHERE provi
nce.id = province_id AND district.id = subdistrict.district_id; QUERY PLAN
----------------------------------------------------------------------------------------------------
Hash Join (cost=7771211730.77..272930003461.72 rows=23422097264624 width=74)
Hash Cond: (district.province_id = province.id)
-> Hash Join (cost=35.61..301.98 rows=7426 width=55)
Hash Cond: (subdistrict.district_id = district.id)
-> Seq Scan on subdistrict (cost=0.00..164.26 rows=7426 width=27)
-> Hash (cost=23.05..23.05 rows=1005 width=36)
-> Seq Scan on district (cost=0.00..23.05 rows=1005 width=36)
-> Hash (cost=3075225689.05..3075225689.05 rows=242863114648 width=27)
-> Nested Loop (cost=0.00..3075225689.05 rows=242863114648 width=27)
-> Nested Loop (cost=0.00..39436753.99 rows=3154066424 width=0)
-> Seq Scan on contact (cost=0.00..3646.99 rows=78899 width=0)
-> Materialize (cost=0.00..7376.64 rows=39976 width=0)
-> Seq Scan on account_invoice (cost=0.00..7176.76 rows=39976 width=0)
-> Materialize (cost=0.00..2.16 rows=77 width=27)
-> Seq Scan on province (cost=0.00..1.77 rows=77 width=27)
(15 rows)
Run Code Online (Sandbox Code Playgroud)
您的日志文件是使用“Windows 行尾”方式创建的。当您使用 Vi 或 Vim 检查时,^M
会显示 (= CR = Carridge Return),因为它不是“Linux End-of-Line”方式的一部分。你可以忽略它。
归档时间: |
|
查看次数: |
439 次 |
最近记录: |