Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Не используется индекс или как ускорить?
|
|||
|---|---|---|---|
|
#18+
Есть таблица ma_data. В ней около 300 тыс строк. Есть в ней поле alias_id. Все NOT NULL и всего их разных 32. Есть индекс по этому полю(btree). Но запросы по типу: Код: plaintext 1. 2. 3. 4. 5. Код: plaintext 1. 2. 3. Код: plaintext 1. 2. 3. 4. Да статистику установил в 998 :) Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2005, 22:47 |
|
||
|
Не используется индекс или как ускорить?
|
|||
|---|---|---|---|
|
#18+
Andrey Daeron ... но все равно проход ВСЕЙ ТАБЛИЦЫ Так у тебя же запрос на проход всей таблицы :-) Да, ты выбираешь только различные alias_id, но чтобы собрать все различные, приходиться просматривать все (чтобы ничего не пропустить :-). Я могу ошибаться, но единственный способ здесь - отдельная таблица, обновляемая триггерами (как это не печально) (приемлимо если изменения таблицы ma-data нечасто происходят (не с частотой 1 Гц) :-) Я могу ошибаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 10:02 |
|
||
|
Не используется индекс или как ускорить?
|
|||
|---|---|---|---|
|
#18+
Funny_Falcon Andrey Daeron ... но все равно проход ВСЕЙ ТАБЛИЦЫ Так у тебя же запрос на проход всей таблицы :-) Да, ты выбираешь только различные alias_id, но чтобы собрать все различные, приходиться просматривать все (чтобы ничего не пропустить :-). Я могу ошибаться, но единственный способ здесь - отдельная таблица, обновляемая триггерами (как это не печально) (приемлимо если изменения таблицы ma-data нечасто происходят (не с частотой 1 Гц) :-) Я могу ошибаться.блинн, ну ясно же, что оптимизатор - кг/ам . Ибо: Код: plaintext 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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 11:30 |
|
||
|
Не используется индекс или как ускорить?
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 11:37 |
|
||
|
Не используется индекс или как ускорить?
|
|||
|---|---|---|---|
|
#18+
4321блинн, ну ясно же, что оптимизатор - кг/ам . Ибо: [src]EXPLAIN ANALYZE (SELECT (SELECT alias_id FROM ma_data WHERE alias_id =1 LIMIT 1) UNION ALL SELECT (SELECT alias_id FROM ma_data WHERE alias_id =2 LIMIT 1) UNION ALL SELECT (SELECT alias_id FROM ma_data WHERE alias_id =32 LIMIT 1) Вот надыбал в рассылке постгреса. Грустно, но факт. With a query of the form: select field,count([field|*]) from table WHERE somefield = somecondition; the query planner is going to have to scan every single row returned by that where clause. There's no shortcut, because the visibility rules of MVCC means you have to look at every tuple IN THE TABLE, not in the index (it's the way postgresql is built, and it isn't likely to change soon, because putting the visibility information in indexes is expensive, and would result in VERY slow updates and very large indexes). So, the best optimization is to use a selective where clause. If you run the query with a where clause of something like: where processdate between '01 july 2005' and '07 july 2005' then you should get better performance. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:21 |
|
||
|
Не используется индекс или как ускорить?
|
|||
|---|---|---|---|
|
#18+
Funny_Falcon Andrey Daeron ... но все равно проход ВСЕЙ ТАБЛИЦЫ Так у тебя же запрос на проход всей таблицы :-) Да, ты выбираешь только различные alias_id, но чтобы собрать все различные, приходиться просматривать все (чтобы ничего не пропустить :-). Я могу ошибаться, но единственный способ здесь - отдельная таблица, обновляемая триггерами (как это не печально) (приемлимо если изменения таблицы ma-data нечасто происходят (не с частотой 1 Гц) :-) Я могу ошибаться. Обьновления могут быть и чаще. До 30-40 инсертов в секунду, и слава богу практически не бывает апдейтов. Решение нашлось просто - по скольку БД нормализирована, то есть справочник с соответсвующими полями, ну а дальше индексируемый JOIN. В общем, все решилось. Но сам факт удручает. В файрбердах таки используется индекс :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:29 |
|
||
|
Не используется индекс или как ускорить?
|
|||
|---|---|---|---|
|
#18+
Andrey Daeron есть справочник с соответсвующими полями, ну а дальше индексируемый JOIN приведите ДЖОНА, т.к. я не сообразил влёт, как его прикрутить. Т.к. из 2х вариаций Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:56 |
|
||
|
Не используется индекс или как ускорить?
|
|||
|---|---|---|---|
|
#18+
4321 Andrey Daeron есть справочник с соответсвующими полями, ну а дальше индексируемый JOIN приведите ДЖОНА, т.к. я не сообразил влёт, как его прикрутить. Подло наврал :) JoIN был в другом месте. Здесь примерно так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 14:22 |
|
||
|
Не используется индекс или как ускорить?
|
|||
|---|---|---|---|
|
#18+
4321блинн, ну ясно же, что оптимизатор - кг/ам. Блин, ты прав. Еще один трабл - если при первом обращении оптимизатор для SELECT ... WHERE alias_id = iid LIMIT 1 выберет seqscan, он его будет применять ко всем остальным. В одной задаче это вызвало жуткие тормоза. Поэтому пришлось сделать запрос динамическим. (по моему так, не помню точно: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. К стати, расшифруй кг/ам (некоторых общеупотребительных сокращений я не знаю :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 14:23 |
|
||
|
Не используется индекс или как ускорить?
|
|||
|---|---|---|---|
|
#18+
Funny_Falcon К стати, расшифруй кг/ам (некоторых общеупотребительных сокращений я не знаю :-) этто из репертуара т.н. "падонкав". Примерно так: "креатиф-ф-ф - г-но/ аффтар - м-к". Жестко, но касательно поведения оптимизатора для этого случая - применимо. В принципе оптимизатор для индексируемого поля для дистинкта по нему должен выполнять что-то типа Код: plaintext 1. 2. А так - либо приходится пользоваться тем, что есть справочник (всех возможных значений индекса), либо тем, что существует известный дискретный набор возможных значений (для целых типов). К сожалению это не всегда выполняется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 14:51 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=33289959&tid=2006979]: |
0ms |
get settings: |
4ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
132ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 437ms |

| 0 / 0 |
