|
|
|
Индекс для ARRAY и POLYGON без PostGIS
|
|||
|---|---|---|---|
|
#18+
Доброго Вам здоровья! Есть таблица с геоданными Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Немного данных Код: sql 1. 2. 3. zips - содержит массив zipcodes poly - полигон соответственно Нужно найти записи которые соответствуют в которых есть нужный zip И заданная точка входит в полигон. Код: sql 1. 2. Хочется полного попадания в индекс т.е. и по zips и по poly Код: sql 1. 2. 3. 4. Я знаю о PostGIS - задание обойтись без него Есть варианты ? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2014, 05:17:24 |
|
||
|
Индекс для ARRAY и POLYGON без PostGIS
|
|||
|---|---|---|---|
|
#18+
Victor Borg, использовать два индекса может только Bitmap Index Scan ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2014, 12:42:07 |
|
||
|
Индекс для ARRAY и POLYGON без PostGIS
|
|||
|---|---|---|---|
|
#18+
ЁшVictor Borg, использовать два индекса может только Bitmap Index Scanу него один составной, и он хотел бы его использовать для проверки обоих пространственных условий. но в случае пространственных индексов это видимо не работает. я вот тоже сижу - морщу репу. задача у меня такая: есть поле, скажем at timestamp[] надо придумать индексирование для шустрой проверки Код: sql 1. 2. ну или сккрестить как-то array[] с range-ем (tsrange ). типа: Код: sql 1. но так, чтобы индексно сие проистекало пока кроме как грубо дискретизировать перед кладкой в [], и искать как overlep с [] дискретов из диапазона - в голову ничё нейдёт. видимо про унутреннюю механнику gin-ов придется чтить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2014, 15:52:27 |
|
||
|
Индекс для ARRAY и POLYGON без PostGIS
|
|||
|---|---|---|---|
|
#18+
Victor Borg, У gist-индекса для полигонов нет поддержки поиска polygon @> point. Зато есть поддержка практически всех операторов с другими полигонами. Попробуйте сделать поиск с вырожденным полигоном: Код: sql 1. Кром этого, в дальнейших экспериментах не забудьте попробовать gist__intbig_ops вместо gist__int_ops. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2014, 16:26:11 |
|
||
|
Индекс для ARRAY и POLYGON без PostGIS
|
|||
|---|---|---|---|
|
#18+
smagen, как движок гиста совмещает внутри массив с полигоном?) вот в чем вопрос) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2014, 17:55:54 |
|
||
|
Индекс для ARRAY и POLYGON без PostGIS
|
|||
|---|---|---|---|
|
#18+
smagen, Спасибо, поиск с вырожденным полигоном действительно работает. Обязательно попробую bigint, но теоретически зачем ? у меня влазит все в int4, int8 за собой тянет увеличение таблицы, индекса. Может там как-то хитро оптимизированно именно для int8? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2014, 20:48:05 |
|
||
|
Индекс для ARRAY и POLYGON без PostGIS
|
|||
|---|---|---|---|
|
#18+
smagen, Двойное спасибо за gist__intbig_ops ! Влияет на количество элементов в массиве (а не на размер элементов), с gist__int_ops при вставке большого количества элементов выдает ошибку о не хватке памяти. Всем спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2014, 22:34:41 |
|
||
|
Индекс для ARRAY и POLYGON без PostGIS
|
|||
|---|---|---|---|
|
#18+
qwwq.......... пока кроме как грубо дискретизировать перед кладкой в [], и искать как overlap с [] дискретов из диапазона - в голову ничё нейдёт.... вот примерная реализация идеи Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. вроде бы выигрыш в наличии очевидно: 1. по воможности уменьшить число массивов-"частей" массива == частей индекса, ( в т.ч., чтобы реже впадать в Bitmap Or) 2. по возможности удешевить ф-ю (т.к. от recheck-ов по ф-ному выражению избавиться снаружи не удастся). (реальное условие будет много сложней) ... 3. придется писать генератор условий запроса по заданному диапазону. Возможно, с отказом от индексного "префикса" -- для слишком широких диапазонов - чтобы избавиться от дорогого счета при фулсканах, и в recheck -- для случая, близкого к full-cscan-у но, возможно, есть более простые решения ? а то у меня глаз замылился. что может предложить ALL ? среднее количество записей в массиве dates_oper -"сэм-восэм". точнее -- около 4.5. Но иногда бывает немногим больше 10-20. //мне желательно ещё иметь возможность всё это совать в btree_gist (экстеншн такой) индекс (т.к. реальная картинка несколько сложнее). а он, вроде бы , не для любого _ops возможен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2014, 13:16:59 |
|
||
|
Индекс для ARRAY и POLYGON без PostGIS
|
|||
|---|---|---|---|
|
#18+
Victor Borg, А какая ошибка возникает при использовании gist__int_ops? Обычно просто индекс становится неэффективным. Misha Tyurin, gist начинает сплитить данные по второму ключу, только если первый ключ совпадает. Надеяться, что будет много повторяющихся полигонов не приходится. Тем не менее есть надежда, что сигнатура по второму ключу будет не везде содержать одни единицы, и всё равно будет полезна при поиске. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2014, 23:29:03 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38663030&tid=1998638]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
277ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
2ms |
| others: | 210ms |
| total: | 586ms |

| 0 / 0 |
