Кстати идея про разбиение. Это может быть просто конфигурационным параметром. Задаете его при заливке в БД и в программе знаете его. Чем меньше блоки, тем больше база, но быстрее сканирование.
Мне этот вариант очень подойдет. У меня редкие поиски и при этом хэндлы могут протухать по утру, а также неудобно следить за протуханием кеша максимального размера блока. Статус прийдется выкинуть, но он не нужен. Отличная получилась дискуссия. Поправлю на днях и соберу новую версию. 2009/12/1 Ruslan Zakirov <[email protected]>: > 2009/12/1 Sergey Zhuravlev <[email protected]>: >> 2009/12/1 Ruslan Zakirov <[email protected]>: >>> Посмотрел EXPLAINы в Pg, стало более понятно. При двух условиях, когда >>> каждое отдельно условие не ограничивает диапазон, оценки количества >>> строк сильно зашкаливают. Это понятно. Не учитывается связь между >>> значениями начала и конца. >>> >>> По этому PG и скорее всего mysql отказываются от index based range >>> scan и переходят к full sequential index scan. Если знать максимальный >>> размер блока ( MAX(iend-istart) ), то, добавив дополнительные условия, >>> можно помочь БД получить более точную оценку и выбрать оптимальный >>> план. >> >> Для ipgeobase это действительно должно сильно помочь. >> >> У нас используется другая база для определения региона по ip, >> и там самая большая сеть 15.0.0.0 - 22.255.255.255 (США) >> Соответственно в нашем случае такая оптимизация не выстрелит ;-) >> Хотя, конечно, можно большие сети разбивать на куски, скажем /16 > > У вас в БД есть блоки покрывающие подсети или вы просто не делаете > локацию внутри США? > > > -- > Best regards, Ruslan. > -- Best regards, Ruslan. -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
