|
Как оптимизировать время выполнения скрипта?
|
||
|---|---|---|
Участник
Откуда: Melbourne, Австралия
Сообщения: 5 148 |
||
| 10.12.2014, 06:56 |
|
|
|
|
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
up ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2014, 15:29 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_me, если не можете переписать запрос -- перепишите планировщик пеже. варианты не переписывая: вариант хинтовать -- не подходит -- хинты в тексте. вариант отэнейблить какой-то способ выполнения -- ? ну и рассмотреть совсем грязные хаки -- попробовать писать самому в pg_statistic какую-то обратимую муть, перед выполнением запроса ах да: варианты погуманнее -- подменять на лету дефолтные операторы, используемые в индексном сравнении, -- если запрос -- это текст, а не распарсенная структура типа вьюхи. Т.е., в вашем случае, забить LIKE каким- то псевдолайком (что- то подобное удружили бортунов сотоварищи в intarray-е, правда не на лету, а раз и навсегда, но заменив дефолтные операторы сравнения массивов своими, из-за чего ихрядная часть ф-й, работающая с одним оператором, вылетает на лету). Т.е. ставим intarray -- переписываем полбазы. сносим intarray -- переписываем по новой) Ещё проще -- на ту же тему, -- перед исполнением сделать свой "upper" -- обертку в своей схеме -- дефолтным (в сёрч-пасе поставить свою ф-ю раньше). В индексе то явно использован pg_catalog.upper, а у вас в запросе, с момента подмены -- "совсем другая ф-я". этим вы предупредите возможность использования индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2014, 16:27 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
кхмits_me, если не можете переписать запрос -- перепишите планировщик пеже. варианты не переписывая: вариант хинтовать -- не подходит -- хинты в тексте. вариант отэнейблить какой-то способ выполнения -- ? ну и рассмотреть совсем грязные хаки -- попробовать писать самому в pg_statistic какую-то обратимую муть, перед выполнением запроса ах да: варианты погуманнее -- подменять на лету дефолтные операторы, используемые в индексном сравнении, -- если запрос -- это текст, а не распарсенная структура типа вьюхи. Т.е., в вашем случае, забить LIKE каким- то псевдолайком (что- то подобное удружили бортунов сотоварищи в intarray-е, правда не на лету, а раз и навсегда, но заменив дефолтные операторы сравнения массивов своими, из-за чего ихрядная часть ф-й, работающая с одним оператором, вылетает на лету). Т.е. ставим intarray -- переписываем полбазы. сносим intarray -- переписываем по новой) Ещё проще -- на ту же тему, -- перед исполнением сделать свой "upper" -- обертку в своей схеме -- дефолтным (в сёрч-пасе поставить свою ф-ю раньше). В индексе то явно использован pg_catalog.upper, а у вас в запросе, с момента подмены -- "совсем другая ф-я". этим вы предупредите возможность использования индекса. я смог разобрать слово "пеже" и то наверно. Может пример из самого простого способа, хотя бы краткий...? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2014, 17:55 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_me, что-то на тему Код: sql 1. 2. 3. 4. далее -- в этом же сеансе делаем EXPLAIN ANALYZE ваших sql-текстов. и убеждаемся, что они таки не умеют [пока] пользоваться индексом, использующим pg_catalog.upper(), т.к. с т.з. текста это public.upper(). -- заворачиваем запрос (тут у вас проблема -- вы же его даже переписать не умеете, чем вы его заворачивать будете) в нечто, делающее за вас это самое set local -- профит. т.е. вопрос -- где вы таки можете вмешаться ? то ли в клиенте что-то сделать, то ли роли для отдельных запросов поменять (в том же клиенте) , а уж для ролей разделить пути и т.п., то ли ещё где-то. если нигде -- то просьба к модератору вас зобанеть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2014, 18:23 |
|
||
|
Как оптимизировать время выполнения скрипта?
|
|||
|---|---|---|---|
|
#18+
its_meup не меняя запросы в приложении вы эту проблему не решите... именно по этому приложени которые потом не предполагается менять с базой должны по ТЗ работать через хранимки создавая слой абстракции который можно менять не меняя код приложения. --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2014, 06:56 |
|
||
|
|
start [/forum/topic.php?fid=53&msg=38829096&tid=1998301]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
176ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
| others: | 278ms |
| total: | 569ms |
| 0 / 0 |
