Daniel Kalchev <daniel@digsys.bg> writes:
> explain
> SELECT sum(input) FROM iplog_gate200112
> WHERE
> '2001-12-01 00:00:00+02' <= ipdate AND ipdate < '2001-12-02 00:00:00+02' AND
> '2001-12-01 00:00:00+02' <= ipdate AND ipdate < '2002-01-01 00:00:00+02' AND
> network_subeq(ipaddr, '193.68.240.0/20') AND 'uni-gw' ~ router;
> results in
> NOTICE: QUERY PLAN:
> Aggregate (cost=51845.51..51845.51 rows=1 width=8)
> -> Seq Scan on iplog_gate200112 (cost=0.00..51845.04 rows=190 width=8)
> Why would it not want to use index scan?
It's difficult to tell from this what it thinks the selectivity of the
ipdate index would be, since the rows estimate includes the effect of
the ipaddr and router restrictions. What do you get from just
explain
SELECT sum(input) FROM iplog_gate200112
WHERE '2001-12-01 00:00:00+02' <= ipdate AND ipdate < '2001-12-02 00:00:00+02' AND '2001-12-01 00:00:00+02' <= ipdate
ANDipdate < '2002-01-01 00:00:00+02';
If you say "set enable_seqscan to off", does that change the plan?
BTW, the planner does not associate function calls with indexes. If you
want to have the ipaddr index considered for this query, you need to write
ipaddr <<= '193.68.240.0/20' not network_subeq(ipaddr, '193.68.240.0/20').
(But IIRC, that only works in 7.2 anyway, not earlier releases :-()
regards, tom lane