Hello. As a note, I ran into the following today (doing a select distinct is fast, doing a count distinct is significantly slower?)
assume a table "issue" with a COLUMN nodename character varying(64);, 7.5M rows... select distinct substring(nodename from 1 for 9) from issue; -- 5.8s select count(distinct substring(nodename from 1 for 9)) from issue; -- 190s SELECT COUNT(*) FROM (SELECT DISTINCT substring(nodename from 1 for 9) FROM issue) as temp; -- 5.5s I have an index on nodename's substring 1 for 9. It struck me as odd that a count distinct would be far slower than selecting distinct rows themselves. Apparently there are other workarounds people have come up with as well [1]. Just mentioning in case it's helpful. Cheers! -roger- [1] http://stackoverflow.com/questions/11250253/postgresql-countdistinct-very-slow/14732410#14732410 explains: explain analyze select count(distinct substring(nodename from 1 for 9)) from issue; Aggregate (cost=222791.77..222791.78 rows=1 width=16) (actual time=190641.069..190641.071 rows=1 loops=1) -> Seq Scan on issue (cost=0.00..185321.51 rows=7494051 width=16) (actual time=0.016..3487.694 rows=7495551 loops=1) Total runtime: 190641.182 ms explain analyze select distinct substring(nodename from 1 for 9) from issue; HashAggregate (cost=222791.77..222846.45 rows=4375 width=16) (actual time=6276.578..6278.004 rows=6192 loops=1) -> Seq Scan on issue (cost=0.00..204056.64 rows=7494051 width=16) (actual time=0.058..4293.976 rows=7495551 loops=1) Total runtime: 6278.564 ms explain analyze SELECT COUNT(*) FROM (SELECT DISTINCT substring(nodename from 1 for 9) FROM issue) as temp; Aggregate (cost=222901.14..222901.15 rows=1 width=0) (actual time=5195.025..5195.025 rows=1 loops=1) -> HashAggregate (cost=222791.77..222846.45 rows=4375 width=16) (actual time=5193.121..5194.454 rows=6192 loops=1) -> Seq Scan on issue (cost=0.00..204056.64 rows=7494051 width=16) (actual time=0.035..3402.834 rows=7495551 loops=1) Total runtime: 5195.160 ms