Postgresql 日志“^M”的含义

Sij*_*tha 1 postgresql postgresql-9.1

我在试图弄清楚为什么查询需要很长时间才能执行时遇到了一些麻烦。当我检查日志时,似乎日志可能不完整。 PostgreSQL 日志

我的问题是,什么是^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)

Mar*_*rco 8

您的日志文件是使用“Windows 行尾”方式创建的。当您使用 Vi 或 Vim 检查时,^M会显示 (= CR = Carridge Return),因为它不是“Linux End-of-Line”方式的一部分。你可以忽略它。

  • 而且查询很慢可能是因为你加入了5个表:`FROM省,区,分区,account_invoice,联系人`,只有2个加入条件。这会创建一个交叉连接并返回大量行。 (3认同)
  • 更具体地说,*query* 包含 Windows 行结尾(CR+LF),并且周围的日志文件具有 Unix 行结尾(仅 LF)。Vim(如果它确实是 Vim)突出显示额外的 CR 字符,因为它们与打开文件的模式不一致;如果您打开了一个包含所有 Windows 行结尾的文件,它只会在该模式下读取它。 (2认同)