postgresql 的gui客户端比较多，有开源的，也有商业的。
用得比较多的可能是pgadmin了，有些人可能会用edb的pem。
但实际上这两个gui都有一个小问题，在返回较大的结果集时，会非常的慢。
例如 ：
数据库端创建一个表，插入约30mb数据。
使用edb的pem或者pgadmin连接到数据库 ：
在gui中执行 ：
耗时20秒。
换个执行语句：
3秒返回。
copy与select * 查询的数据量一样多，而且都是全表扫描，但是时间却相差10几秒。
原因排查
在pgadmin客户端的机器上，观察到一个现象 ：
执行select * from test;时，网络使用率不高，持续时间长。
网络传输结束后，cpu马上飙高，估计pgadmin在处理数据，很长一段时间后，才开始展示结果。
而更换为
后，执行非常迅速，而且展示也非常快，可以看到网络使用率很高，出现了一个尖峰。
将gui客户端更换为heidisql后，执行 select * from test; 执行速度很快，与copy相当。
从网络使用率来看，也出现了一个尖峰，数据很快就传完了。
使用 postgresql 客户端 psql 命令执行select * from test，速度也和heidisql一样，很快。
对比以上几种情况，说明pgadmin和pem在处理 select 时，效果并不理想，如果要返回大量的结果集，请慎用。
如果使用pem或者pgadmin要返回大量结果集，建议使用游标来返回：
例子：
网络流量对比图 :
从左往右数
第1个尖峰，heidisql中执行select * from test;
第2个尖峰，pgadmin中执行copy (select * from test) to stdout;
第3个尖峰，pgadmin中执行copy test to stdout;
第4个尖峰，psql中执行select * from test;
说明 select * from test 的网络传输流量确实比copy的更大一些。
heidisql不支持 copy命令.
如果你用的是windows平台，并且遇到了与之类似的问题，建议排查一下客户端程序的代码，从程序层面来解决这个问题。
这个问题我也会反馈给pgadmin和edb，看看他们怎么解决。
最后要给应用开发人员的一个小建议 :
查询大结果集，给用户展示数据的sql，建议修改为用游标打开，一次fetch少量数据, 拿到数据马上就可以向用户展示，后台可以根据策略选择是否再继续fetch剩余的数据。
这样做的好处是用户体验更好，同时有可能可以大大减少数据库的网络开销和cpu开销（因为用户并不一定要查询所有数据）如果用户关闭窗口，可以不再fetch其他数据。
大多数类似的应用场景，都是这样来设计的。