Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
изменить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Всем доброго дня! Есть запрос Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. После Код: plaintext 1. Код: plaintext 1. 2. 3. 4. 5. 6. Как бы загнать под второй план, не используя SET enable_seqscan to off ? p.s. функция text_delim_to_set возращает SETOF, например для запроса: Код: plaintext 1. Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2008, 10:11 |
|
||
|
изменить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
а вот так что скажет: Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2008, 10:44 |
|
||
|
изменить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
4321а вот так что скажет: Код: plaintext 1. 2. 3. 4. 5. 6. Так попробовал в певую очередь получилось следующее Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. после изменения statistics_target = 1000 для столбцов таблицы и последующим analyze план стал выбираться "правильный" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2008, 11:19 |
|
||
|
изменить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Gold_-> Function Scan on text_delim_to_set (rows=1000) (actual rows=3)Проблема в неправильной оценке постгресом кол-ва строк, возвращаемых функцией. В новой версии постгреса при создании функции можно указать параметры "ROWS result_rows" и "COST execution_cost", которые будет использовать постгрес для оценки при выборе плана. В вашей старой версии такой возможности нет. Нашел мое письмо в рассылку четырехлетней давности, то есть постгрес тогда был старый, правда его кажется не зааппрувили. У нас была похожая проблема. Решили кажется заменой в исходниках глобальной константы 1000 на 20, так как все используемые у нас функции выдают примерно столько строк. There is "rel->tuples = 1000" hardcoded in the set_function_size_estimates() from backend/optimizer/path/costsize.c. But in my case function glb_get() returns as usual 10 - 30 rows. It seems that if planner would have correct idea about this, it chooses another plan using Nested Loops. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2008, 11:24 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=35244611&tid=2004448]: |
0ms |
get settings: |
6ms |
get forum list: |
17ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
33ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 310ms |

| 0 / 0 |
