PostGIS geography intersect slower than geometry intersect
As @LR1234567 pointed out, the geography version of ST_Intersects is really just a wrapper around a distance calculation. If your geographies contain a lot of vertices, you may get better performance by forcing PostGIS to use a tree-based distance calculation.
This algorithm is much faster than the brute-force distance calculation, but PostGIS makes the wager that it's only worth using it when the tree can be reused multiple times. You can override this logic and force the use of the tree-based calculation like this:
SELECT DISTINCT g1.iso, g2.iso FROM gadm g1, gadm g2
WHERE g1.geog && g2.geog
AND g1.iso!=g2.iso
AND _ST_DistanceTree(g1.geog, g2.geog) < 0.00001
The geography functions are slower because they do a lot more. Also not as much time has been spent on beefing up the performance of geography functions since most people still use geometry.
It varies how bad the difference is. AS I recall point to point distance checks and ST_Dwithin point to point are just slightly slower.
polygons are really bad and how bad they are is a function of how many points you've got in your polygon and the coverage of it. It's generally at least 10 times worse than geometry.
ST_Intersects in geometry for example uses a lot of short-cuts which rely on intersection matrix that geography can't. So a better comparison would be ST_DWithin geometry / ST_Intersects geography since geography ST_Intersects is really a wrapper around the geography ST_DWithin plumbing which relies on the distance plumbing.
Even then you'll find geometry is much faster. I think some of those faster pieces in geometry distance plumbing are something that can be added to geography. There just hasn't been enough demand / funding for that kind of work to make it happen.
One more thing. Can you do me a favor and compare the performance of
&& (using geography and geometry)
from what I recall, the bounding box performance is closer in performance but really looses it if it has to hit the core functions.