Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Оптимизатор - выбор индекса
|
|||
|---|---|---|---|
|
#18+
День добрый. Есть таблица TempInfo: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. "Sort (cost=3.14..3.15 rows=1 width=47) (actual time=69.081..69.082 rows=2 loops=1)" " Sort Key: count(infoid)" " -> HashAggregate (cost=3.13..3.13 rows=1 width=47) (actual time=69.060..69.067 rows=2 loops=1)" " -> Index Scan using "IX_TempInfo_CreateDate" on TempInfo (cost=0.00..3.13 rows=1 width=47) (actual time=0.027..52.438 rows=15063 loops=1)" " Index Cond: ((createdate >= '2006-03-27'::date) AND (createdate <= '2006-03-27'::date))" "Total runtime: 69.165 ms" На мой взгляд, было логичнее и быстрее использовать индекс IX_TempInfo_CreateDate_Info. Не ясно почему оптимизатор этого не делает. Хотелось бы узнать Ваше мнение по этому вопросу. И есть у постгреса возможность задать хинт для оптимизатора, то есть принудительно указать тот индекс, который нужно использовать при выполнении запроса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2006, 18:51 |
|
||
|
Оптимизатор - выбор индекса
|
|||
|---|---|---|---|
|
#18+
>>На мой взгляд, было логичнее и быстрее использовать индекс IX_TempInfo_CreateDate_Info. Почему ты так считаешь? Если добавить Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 07:57 |
|
||
|
Оптимизатор - выбор индекса
|
|||
|---|---|---|---|
|
#18+
Alexey.ChaleyНа мой взгляд, было логичнее и быстрее использовать индекс IX_TempInfo_CreateDate_Info.Для запроса вида "where field1 between A and B order by [group by] field2" индекс по (field1,field2) не полезнее, чем индекс по (field1). Так как (при использовании плана GroupAggregate) после выборки записей по индексу (field1,field2) их нужно пересортировать в порядке field2. В вашем случае A=B (BETWEEN '2006-03-27' AND '2006-03-27'), но постгрес, как видно из плана запроса, этого не заметил. Замените на CreateDate='2006-03-27', подскажите ему. :) Тогда наверное он выберет ожидаемый план. Alexey.ChaleyИ есть у постгреса возможность задать хинт для оптимизатора, то есть принудительно указать тот индекс, который нужно использовать при выполнении запроса?Такой возможности нет. Есть только команды set enable_* to on|off. Причем влияющие на план запроса целиком, а например не на вложенный подзапрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 08:31 |
|
||
|
|

start [/forum/topic.php?fid=53&gotonew=1&tid=2006524]: |
0ms |
get settings: |
5ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
50ms |
get topic data: |
8ms |
get first new msg: |
5ms |
get forum data: |
3ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 228ms |
| total: | 345ms |

| 0 / 0 |
