I'm running right now with a dev build which was configured with
--enable-cassert (and --enable-debug). Just out of curiosity, I re-ran
the query which chose the sort and mergejoin over the (faster) nested
index scan. The results seem interesting, although I'd need more tests
to consider them entirely reliable. I've divided the actual run time
(in ms) by the cost estimate, to come up with the ratio of ms per unit
of estimated cost. I'll round to three significant digits, based on
observed variation from one test to another.

==============================
WITH --enable-cassert
==============================

uncached sort/merge: 0.194
uncached nested scan: 0.288

cached sort/merge: 0.0340
cached nested scan: 0.0560

==============================
WITHOUT --enable-cassert
==============================

uncached sort/merge: 0.182
uncached nested scan: 0.0478

cached sort/merge: 0.0256
cached nested scan: 0.00494

This shows me that when assertions are being tested, the cost estimates
are slightly skewed to favor nested scans. When assertions are not
tested, costs seem to be significantly distorted in favor of the
sort/merge. The assertion load on the index scan seems to be extreme.
It'll take some time to make sure that I can reproduce this, but I
wanted to put this out there for comment and possible independent
confirmation.

-Kevin


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> [$subject]

No, the planner has no idea about the cost of Asserts.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match