Hello,
I've followed the last discussion about the particular case of
"select count(*)"s on large tables being somewhat slow.
I've seen also this issue already on the todo list, so I know
it is not a simple question.
This problem arises for me on very large tables, which I mean
starting from 1 million rows and above.
The alternative solution I tried, that has an optimal
speed up, unfortunately is not a way out, and it is based
on "EXPLAIN SELECT count(*)" output parsing, which
is obviously *not* reliable.
The times always get better doing a vacuum (and eventually
reindex) of the table, and they slowly lower again.
Is there an estimate time for this issue to be resolved?
Can I help in some way (code, test cases, ...)?
--
Cosimo
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
