Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток. PostgreSQL 9.2.14 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bit есть таблица Код: 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. Для запроса похожего на Код: sql 1. 2. 3. план Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Почему так долго? Для массива из 1000 план Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Время уходит на фильтрацию? Теперь основной вопрос Пытаюсь сделать индекс Код: sql 1. 2. 3. 4. не закончился за 17 часов Решил все прервать запустить монопольно. Прервал после 1,5 часа. Кто виноват и что делать? (с) p.s. 9.6 такой запрос ускорит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 12:36 |
|
||
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
Gold_, а какую задачу решаете ? индекс не может быть использован на не иммутабное значение -- пж обычно надо уметь узнать значение при составлении плана. это возможно для литерала или для имутабной ф-ии. и то не для всякой. например литерал date'today' сильно выгоднее "константы" current_date -- именно потому, что предвычисляется при составлении плана. (в плане будет торчать величина) а результат агрегата -- именно не--иммутабен. Предвычислите его клиентом и передайте параметром -- может начать что--то использовать. Но вы ведь и индекс построить не можете . Какой длины у вас средний массив ? И зачем вам искать пересечение аж с 100000,, при ~ляме записей. Тут уж секскан будет всего вероятнее именно что дешевле. (порядка 1/10 ожидаемый возврат). очень может оказаться , что реляционная подчинёнка с нормальным индексом + какой--либо вариант самопального loose-индекскана у вас бы катил много шустрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 12:58 |
|
||
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
qwwq, Спасибо. В приведенных примерах я не ищу 100000 записей. В первом 3000 случайных записей, во втором 1000. В реальной системе конечно же массив приходит реальный, а не случайный ). Подавляющее большинство (99% ) длина массива 1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 13:45 |
|
||
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
Gold_Почему так долго?2 млн строк на 3 тыс элементов массива = 6 млрд операций сравнения. За тысячу секунд не так уж и долго. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 14:46 |
|
||
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
Gold_, а случайно intarray экстеншн не поставлен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 15:21 |
|
||
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
Alexius, поставлен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 15:32 |
|
||
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
Gold_, ну вот виновник скорей всего. попобуйте со штатным оператором && запрос выполнить Код: sql 1. 2. 3. или спилите экстеншн, если не используется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 15:37 |
|
||
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
Gold_, Отвечу на основной вопрос. Читаю за вас докуметацию: " Two GiST index operator classes are provided: gist__int_ops (used by default) is suitable for small- to medium-size data sets, while gist__intbig_ops uses a larger signature and is more suitable for indexing large data sets (i.e., columns containing a large number of distinct array values). The implementation uses an RD-tree data structure with built-in lossy compression. " (и не создастся он по большой таблице без gist__intbig_ops за разумное время) Ну и обязательно поставить большой maintenance_work_mem (4Gb например если памяти на сервере достаточно) на время создания индекса. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 15:43 |
|
||
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
Alexius, Спасибо. Быстрее в разы. Модуль используем. Может не стоит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 16:00 |
|
||
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Спасибо. В доке же указанно только для больших массивов. "и не создастся он по большой таблице без gist__intbig_ops за разумное время)" это же Ваш опыт? да и не думал я, что это очень большая таблица. Еще раз спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 16:02 |
|
||
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
Gold_Alexius, Спасибо. Быстрее в разы. Модуль используем. Может не стоит? план покажите, да ps мне , после накатки интеррея (в дефолтную схему) в тесте приходилось префиксы в динамику хранимок задним числом впихивать -- т.к. индекс был построен со стандартным оператором, а после перекрытия интерреевским -- не подхватывался. надо бы другой оператор использовать авторам (наш колхоз об таком не думает) -- в любом случае либо у одного либо у другого придётся префикс писать. маленькое неудобство, а спотыкаешься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 16:18 |
|
||
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
С указанной Maxim Boguk опцией индекс создался. Индекс используется для оператора из intarray. Время поиска 1000 записей 120 сек Для штатного оператора индекс не используется, что очевидно. Время поиска 1000 записей 26 сек. qwwq, план чего показать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 16:41 |
|
||
|
не могу сделать индекс
|
|||
|---|---|---|---|
|
#18+
Gold_, Сделал также gin-индекс. Для штатного оператора с использованием gin-индекс. Время поиска 1000 записей 300мс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 17:00 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=85&tid=1996968]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
63ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
74ms |
get tp. blocked users: |
2ms |
| others: | 14ms |
| total: | 191ms |

| 0 / 0 |
