(I changed the title, since it was a red herring.)
To be blunt, this is hard to optimize:
where ip_start<=1582783255 and ip_end>=1582783255;
I don't know how Postgres does as good a job as you (and others) say.
Thomas's suggested index is a good start. That lets
SELECT id FROM ...
work sort of fast because it stays in the Index, and does not have to touch the data. If `id` is all you are looking for, that's about all I can say.
If you need more than `id`, then use a JOIN:
SELECT r.*
FROM range r
JOIN range x ON r.id = x.id
WHERE x.ip_start<=1582783255 and x.ip_end>=1582783255;
That tricks it into scanning part of the index to get a collection of x.id (hopefully a small list), then reaching into r to get the other columns you need.
Maybe I said more in some of these:
http://forums.mysql.com/read.php?24,407239 (Slow query)
http://forums.mysql.com/read.php?115,358298 (How can I optimize this query?)
http://forums.mysql.com/read.php?10,356125 (update big table cause an excution time out)
http://forums.mysql.com/read.php?10,293341 (Help with the best table layout for message board)
http://forums.mysql.com/read.php?10,278476 (Can a Mysql MyISAM or InnoDB table benefit from the STRIPE feature of disk device?)
http://forums.mysql.com/read.php?10,278480 (Can a Mysql MyISAM or a InnoDB table benefit from a set of multi-thread and multi-disk I/O device?)
http://forums.mysql.com/read.php?10,255092 (What data type should I use and what storage engine?)
http://forums.mysql.com/read.php?24,229499 (optimize IP range join: postgresql is 496 times faster)
http://forums.mysql.com/read.php?24,215326 (Optimize IP Range Join)
There are more complicated ways that are much faster, but I don't have a whitepaper on such (yet).
(A similar problem exists with TV listings times, but those tables are usually smaller.)
A new thought: PARTITION on the top 9 bits of the IP. But you must make sure no range spills across partitions. This would at least bound the problem that you are having -- scanning up to half the index. With this, the index being scanned is only 1/512 of the original. But, as I say, "more complicated".