Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
день добрый! помогите плз разобраться с запросом. у меня вьюха в базульке есть. выполнение её оч тормозит. вроде как она не самая сложная и объём отрабатываемых ею данных кажыся тоже не оч велик. всё это наводит на мысли что это я гдето протупил. натыкал везде где мог индексов - не помогает. но кажыся и не мешает :) - вроде медленнее работать не стало :). разбирался с кодом запроса. с данными утех объяснений графических и текстовых ничего не понял - кост, видз и т.п. - полностью не понимаю что это :). ну и ещё глючит что-то пгадмина бетта - текст/графически в меню перепутаны местами и графически ерунду вообще выдаёт :(. выдаёт токо знак вопроса и селект лист. вобщем выяснил я что в коде запроса тормозит именно вот этот кусок: Код: plaintext 1. 2. 3. 4. 5. 6. 7. именно на этом месте пробуксовки на 6-7 секунд. подскажите плз как побороть это. ну и вообще в чём причина этого явления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2007, 12:35 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
а в таком виде работает за 150мс - против 6-7 секунд: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. т.е. получается основные пробуксовки на <>all. то, чему оно <> тоже шустро выбирается очень. т.е. на проверке <> all мы буксуем. может как-то это другим способом сделать?... как ещё можно это сделать - чтобы быстрее было - с тем же результатом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2007, 13:00 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
вот может вот это ещё кому-то о чём-то скажет - я тут мало что понимаю :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2007, 13:19 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
покажите лучше выдачу "EXPLAIN ANALYZE SELECT ..." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2007, 13:27 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat ALL на Exist не имеет смысл заменить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2007, 13:34 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
aov вобщем выяснил я что в коде запроса тормозит именно вот этот кусок: Код: plaintext 1. 2. 3. 4. 5. 6. 7. именно на этом месте пробуксовки на 6-7 секунд. подскажите плз как побороть это. ну и вообще в чём причина этого явления. На будующее - ВСЕГДА высылайте explain analyze для Вашего запроса. Это всегда хорошо, поскольку как минимум позволяет определить порядок количества записей в выборках. Без него - практически всегда - шаманство. что-то по типу (в скобочках не уверен, но направление я думаю будет понятно) : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2007, 13:38 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
вот это до 50мс работает :) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. хотя я так и не понял в чём же принципиальная разница между <>all(select...) и not exists(select...). оно как-то по разному обрабатывается сервером? и зачем тогда <>all :) - вроде как его всегда можно на not exists переписать . . . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2007, 15:44 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
LeXa NalBatпокажите лучше выдачу "EXPLAIN ANALYZE SELECT ..." Andrey Daeron .. На будующее - ВСЕГДА высылайте explain analyze для Вашего запроса. Это всегда хорошо, поскольку как минимум позволяет определить порядок количества записей в выборках. Без него - практически всегда - шаманство. .. Если опытные товарищи говорят, что надо выслать план - высылайте... теперь для обоих, пжл, любопытно ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2007, 09:53 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
вот not exists: "QUERY PLAN""HashAggregate (cost=53449.73..53462.40 rows=845 width=23) (actual time=95.939..96.002 rows=21 loops=1)"" -> Merge Join (cost=0.00..53426.38 rows=3113 width=23) (actual time=34.203..95.611 rows=34 loops=1)"" Merge Cond: (z.id = p.fk_zak_tochki)"" -> Index Scan using zak_tochek_id_idx on zak_tochek z (cost=0.00..22.35 rows=158 width=4) (actual time=0.025..0.482 rows=161 loops=1)"" Filter: ok"" -> Index Scan using zt_poz_fk_zak_tochki_idx on zak_tochek_poz p (cost=0.00..53365.48 rows=3212 width=27) (actual time=33.839..94.527 rows=34 loops=1)"" Filter: (NOT (subplan))"" SubPlan"" -> Index Scan using zt_poz_idx on ztochek_to_zpost ztzp (cost=0.00..8.27 rows=1 width=8) (actual time=0.007..0.007 rows=1 loops=6488)"" Index Cond: ($0 = fk_ztochek_poz)""Total runtime: 96.213 ms" а это <> all: "QUERY PLAN""GroupAggregate (cost=135.38..262051.48 rows=845 width=23) (actual time=16895.819..104265.982 rows=21 loops=1)"" -> Nested Loop (cost=135.38..262015.46 rows=3113 width=23) (actual time=12210.188..104265.388 rows=34 loops=1)"" -> Index Scan using zt_poz_fk_tov_idx on zak_tochek_poz p (cost=135.38..261079.84 rows=3212 width=27) (actual time=12210.143..104263.588 rows=34 loops=1)"" Filter: (subplan)"" SubPlan"" -> Materialize (cost=135.38..200.27 rows=6489 width=8) (actual time=0.003..7.704 rows=3244 loops=6488)"" -> Seq Scan on ztochek_to_zpost (cost=0.00..128.89 rows=6489 width=8) (actual time=0.014..19.300 rows=6454 loops=1)"" Filter: (fk_ztochek_poz IS NOT NULL)"" -> Index Scan using zak_tochek_id_idx on zak_tochek z (cost=0.00..0.28 rows=1 width=4) (actual time=0.025..0.030 rows=1 loops=34)"" Index Cond: (p.fk_zak_tochki = z.id)"" Filter: ok""Total runtime: 104266.598 ms" я что-то слабо понимаю что это всё значит и в чём реально разница. GroupAggregate этот и Nested Loop в случае с all - и HashAggregate & Merge Join при not exists . . . в этом дело? и в чём разница между агрегатами этими? ну с нестед луп и мерге джойн яснее вроде - хотя тоже не оч. ну тут интуитивная есть догадка что джойн быстрее лупа должно быть :). как-то бы блин разобраться с этим на будущее.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2007, 10:46 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
Уважаемые Гуру. Опишите, пжл, планы: типа: сначало выполняется вложенные запрос, путем перебора всех записей.. Учусь читать планы PG, думаю, не мне одному будет интересно. Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2007, 11:34 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
Ну, может гуру поправят, но я понимаю это так: Код: plaintext 1. seqscan - последовательное чтение из таблицы ztochek_to_zpost, стоить это будет 128.89 попугаев, первая строчка будет в 0.00, а последняя 128.89, планирую выгребсти 6489 строк, шириной 8 байт. Асилил первую строчку в 0,014 послденюю 19,300, 6454 строк и делал это (и поидее все нижнее) аж 1 раз. Materialize - ХЗ что (может фиксирование в памяти результата как таблицы?), опять же поччти ничего не стоит первая строчка в 138,38, послденяя в 200,27 попугаев, строк 6489 шириной 8, асилил же первую строчкув 0,003, послднюю в 7,704, 3244 строк,а вот делать это буду 6488 раз (примерно ). Код: plaintext 1. 2. словарик (гуру и не только - дополняйте, сам далеко не все знаю): Seq Scan - тупой, последовательный чтений всех записей из таблицы с провркой (или без) условия Index Scan -чтение данных из таблицы с использованием индексов (далее указывается условие для индекса) Merge Join - слияние двух баличных представлений (таблиц, подселектов и т.д) методом merge - т.е. ИМХО тупого слияния. GroupAggregate - аггрегирование по группам. Просто аггрегирование. HashAggregate - Аггрегирование по построенному для каждой строки хешу (ИМХО лучше чем group, хотя чем - не знаю). Дополняйте, подхватывайте, исправляйте - хороший ФАКовый вопрос получиццо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2007, 16:47 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
aovя что-то слабо понимаю что это всё значит и в чём реально разница. Gold_Опишите, пжл, планы: типа: сначало выполняется вложенные запрос, путем перебора всех записей..наверное в инете можно почитать про планы запросов. я неделю врубался в "плановую" главу в книжке "Oracle Performance Tuning", потом при переходе на постгрес обнаружил, что этапы выполнения запросов такие же. имхо, можно почитать про планы безотносительно постгреса, так как это "общая математика" для всех СУБД. план в выдаче EXPLAIN можно читать справа налево, то есть от наиболее глубоких этапов - к использующим их этапам. aovGroupAggregate этот и Nested Loop в случае с all - и HashAggregate & Merge Join при not exists . . . в этом дело?планы сильно отличаются, у них оказалась сильно разная скорость выполнения. я не припомню быстрого плана с Materialize :-( aovи в чём разница между агрегатами этими?GroupAggregate принимает на вход отсортированный массив, последовательно выполняет уникализацию ключей (аналогично юниксовой утилите uniq) и накопление значений (через агрегатные функции) HashAggregate принимает на вход неотсортированные данные, засовывает во временный хэш ключи и соответствующие им аггрегированные значения, после чего возвращает данные из хэша aovну с нестед луп и мерге джойн яснее вроде - хотя тоже не оч. ну тут интуитивная есть догадка что джойн быстрее лупа должно быть :)по разному бывает, оба быстрые :-) aovкак-то бы блин разобраться с этим на будущее....на будущее - для каждого интересующего запроса надо смотреть план, искать в нем узкое/медленное место, пытаться придумать лучший план, пытаться добиться от постгреса выбора этого плана Andrey DaeronMaterialize ... делать это буду 6488 раз (примерно ).видимо это actual loops, то есть реальные, а не предсказанные. почему же тогда "примерно"? Andrey DaeronMerge Join - слияние двух баличных представлений (таблиц, подселектов и т.д)я бы назвал слияние двух отсортированных потоков Andrey DaeronHashAggregate ... (ИМХО лучше чем group, хотя чем - не знаю).наверное для запроса "... where X between ... group by X order by X" при наличии индекса по X план GroupAggregate окажется быстрее, потому что не будет требовать наличия после себя этапа Sort, так как входы и выход у GroupAggregate отсортированы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2007, 17:23 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat..план в выдаче EXPLAIN можно читать справа налево, то есть от наиболее глубоких этапов - к использующим их этапам. .. в смысле снизу вверх? и все таки, хотя бы один, плиз.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2007, 18:52 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
Gold_ LeXa NalBatплан в выдаче EXPLAIN можно читать справа налево, то есть от наиболее глубоких этапов - к использующим их этапам.в смысле снизу вверх?нет, справа налево с уменьшением отступов. например запись Код: plaintext 1. 2. 3. 4. Gold_и все таки, хотя бы один, плиз..В главе 13.1. Using EXPLAIN объясняются основные этапы. Там больше одного примера. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2007, 19:40 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat..нет, справа налево с уменьшением отступов. например запись Код: plaintext 1. 2. 3. 4. Спасибо. То что нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2007, 09:46 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat... в "плановую" главу в книжке "Oracle Performance Tuning"... А кто автор? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2008, 13:48 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
Gold_ LeXa NalBat... в "плановую" главу в книжке "Oracle Performance Tuning"...А кто автор?книжка древняя, на английском Oracle Performance Tuning (Covers Versions 6 and 7) by Peter Corrigan and Mark Gurry 1993 O'Reilly & Associates, Inc. ISBN: 1-56592-048-1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2008, 10:10 |
|
||
|
тормозит жостко запрос
|
|||
|---|---|---|---|
|
#18+
блин, нашел только на амазоне... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2008, 14:34 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=34898966&tid=2004634]: |
0ms |
get settings: |
9ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
50ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
34ms |
get tp. blocked users: |
1ms |
| others: | 259ms |
| total: | 375ms |

| 0 / 0 |
