"Jeff Boes" <jboes@nexcerpt.com> writes:
> This leads me to the conclusion that either postgres has a
> bug that is preventing it from actually using the operator
> that is defined on the index (thus falling back to the non-
> indexed comparison), or explain is broken, or my understanding
> of indexes is broken.
The latter. You are neglecting the fact that an indexscan on an
'=' condition (scan only those values '=' to something) is normally
a lot more selective than an indexscan on a '>=' condition (scan
from that value to the end).
In your example, the '=' condition is estimated to select only
one row, whereas the '>=' condition is estimated to select
39884 rows, or about 10% of the table. If that estimate is
accurate then very probably the planner made the right choice
--- indexscans that touch more than a couple percent of the table
are normally losers in Postgres, compared to a simple sequential
scan (mainly because Unix kernels like to read ahead on sequential
reads, so seqscan cooperates with the kernel instead of fighting it).
Since you didn't tell us how many rows are really involved, nor
what the actual runtimes were with and without the enable_seqscan
change, we can't tell how close the planner's estimates are to
reality. But there's no a-priori evidence of brokenness here.
regards, tom lane
