left join的结果只会比inner join多。这么写的话，如果关联条件会命中多次，关联数据很可能会膨胀。如果最后有过滤条件的话，这种写法是没问题的，优化器会把条件下推到扫描，关联的数据会变小。

如果是在不同层次的子查询，比如select CASE WHEN num='one' THEN 1 WHEN num='two' THEN '2 ELSE 3 as num2 from( CASE WHEN t1.a=1 THEN 'one' WHEN t1.a=2 THEN 'two' ELSE 'other' as num from t1) t这种语句在一开始不会占用很大，但是在进行子查询提升的查询重写时，也会把父查询中的num替换成子查询中的表达式

主要是优化器会比较耗内存。同一个子查询内，嵌套case when时，会把非基表列的输出列展开，导致表达式膨胀的很大。例如CASE WHEN t1.a=1 THEN 'one' WHEN t1.a=2 THEN 'two' ELSE 'other' as num,CASE WHEN num='one' THEN 1 WHEN num='two' THEN '2 ELSE 3 as num2num2里每个num都会被展开成上面的case when，导致num2的结构就变成CASE WHEN (CASE WHEN t1.a=1 THEN 'one' WHEN t1.a=2 THEN 'two' ELSE 'other)='one' THEN 1 WHEN (CASE WHEN t1.a=1 THEN 'one' WHEN t1.a=2 THEN 'two' ELSE 'other)='two' THEN '2 ELSE 3 as num2case when的嵌套数和分支数越多，表达式越复杂，导致一个表达式所占的内存就很高。

SELECT * FROM pgxc_get_table_skewness;

断连的时候，数据库有返回报错信息吗？大长SQL无法正常执行，可能是设置了超时，或者是客户端的内存不足，缓存不了那么大的

可能是因为其中某个快照数据有问题，导致生成wdr报告告警。可以通过dbms_om.snap_(视图名)直接查看这两个快照id的数据看是哪个有问题。或者查看pg_log日志看看有什么报错。

这个报错应该是jdbc的报错，clients应该只是外部链接，max connections这个限制是包括内部链接和外部链接的。