powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / тормозит жостко запрос
19 сообщений из 19, страница 1 из 1
тормозит жостко запрос
    #34893936
Фотография aov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
день добрый!
помогите плз разобраться с запросом. у меня вьюха в базульке есть. выполнение её оч тормозит. вроде как она не самая сложная и объём отрабатываемых ею данных кажыся тоже не оч велик. всё это наводит на мысли что это я гдето протупил.
натыкал везде где мог индексов - не помогает. но кажыся и не мешает :) - вроде медленнее работать не стало :).
разбирался с кодом запроса. с данными утех объяснений графических и текстовых ничего не понял - кост, видз и т.п. - полностью не понимаю что это :). ну и ещё глючит что-то пгадмина бетта - текст/графически в меню перепутаны местами и графически ерунду вообще выдаёт :(. выдаёт токо знак вопроса и селект лист.

вобщем выяснил я что в коде запроса тормозит именно вот этот кусок:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SELECT p.fk_tov, sum(p.kvo) AS kvo, sum(p.kvo2) AS kvo2
           FROM zak.zak_tochek_poz p
      JOIN zak.zak_tochek z ON p.fk_zak_tochki = z.id
     WHERE z.ok = true AND (p.id <> ALL ( SELECT ztochek_to_zpost.fk_ztochek_poz
              FROM zak.ztochek_to_zpost
             WHERE ztochek_to_zpost.fk_ztochek_poz IS NOT NULL))
     GROUP BY p.fk_tov
там это как вложенный запрос испоьзуется - селект ... фром (селект ...) джойн то джойн сё...
именно на этом месте пробуксовки на 6-7 секунд.
подскажите плз как побороть это. ну и вообще в чём причина этого явления.
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34894057
Фотография aov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а в таком виде работает за 150мс - против 6-7 секунд:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SELECT p.fk_tov, sum(p.kvo) AS kvo, sum(p.kvo2) AS kvo2
           FROM zak.zak_tochek_poz p
      JOIN zak.zak_tochek z ON p.fk_zak_tochki = z.id
/*     WHERE z.ok = true AND (p.id <> ALL 
		( SELECT ztzp.fk_ztochek_poz  
			FROM zak.ztochek_to_zpost ztzp
			WHERE ztzp.fk_ztochek_poz IS NOT NULL
		)
	)
  */   GROUP BY p.fk_tov

т.е. получается основные пробуксовки на <>all. то, чему оно <> тоже шустро выбирается очень. т.е. на проверке <> all мы буксуем. может как-то это другим способом сделать?... как ещё можно это сделать - чтобы быстрее было - с тем же результатом?
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34894154
Фотография aov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вот может вот это ещё кому-то о чём-то скажет - я тут мало что понимаю :)
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34894202
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
покажите лучше выдачу "EXPLAIN ANALYZE SELECT ..."
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34894230
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LeXa NalBat
ALL на Exist не имеет смысл заменить?
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34894257
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aov
вобщем выяснил я что в коде запроса тормозит именно вот этот кусок:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SELECT p.fk_tov, sum(p.kvo) AS kvo, sum(p.kvo2) AS kvo2
           FROM zak.zak_tochek_poz p
      JOIN zak.zak_tochek z ON p.fk_zak_tochki = z.id
     WHERE z.ok = true AND (p.id <> ALL ( SELECT ztochek_to_zpost.fk_ztochek_poz
              FROM zak.ztochek_to_zpost
             WHERE ztochek_to_zpost.fk_ztochek_poz IS NOT NULL))
     GROUP BY p.fk_tov
там это как вложенный запрос испоьзуется - селект ... фром (селект ...) джойн то джойн сё...
именно на этом месте пробуксовки на 6-7 секунд.
подскажите плз как побороть это. ну и вообще в чём причина этого явления.
На будующее - ВСЕГДА высылайте explain analyze для Вашего запроса. Это всегда хорошо, поскольку как минимум позволяет определить порядок количества записей в выборках. Без него - практически всегда - шаманство.

что-то по типу (в скобочках не уверен, но направление я думаю будет понятно) :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
SELECT pp.fk_tov, sum(pp.kvo) AS kvo, sum(pp.kvo2) AS kvo2
FROM 
 zak.zak_tochek_poz pp
INNER JOIN 
(SELECT p.id
           FROM zak.zak_tochek_poz p
      JOIN zak.zak_tochek z ON p.fk_zak_tochki = z.id
     WHERE z.ok = true)
MINUS
(
( SELECT ztochek_to_zpost.fk_ztochek_poz
              FROM zak.ztochek_to_zpost
             WHERE ztochek_to_zpost.fk_ztochek_poz IS NOT NULL)
) gi on (pp.id=gi.id)
     GROUP BY p.fk_tov
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34894778
Фотография aov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вот это до 50мс работает :)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
SELECT p.fk_tov, sum(p.kvo) AS kvo, sum(p.kvo2) AS kvo2
FROM zak.zak_tochek_poz p
JOIN zak.zak_tochek z ON p.fk_zak_tochki = z.id
WHERE z.ok = true  AND not exists( 
	( SELECT  ztzp.fk_ztochek_poz  
		FROM zak.ztochek_to_zpost ztzp
		WHERE ztzp.fk_ztochek_poz IS NOT NULL and p.id = ztzp.fk_ztochek_poz
	))
GROUP BY p.fk_tov
большое спасибо!
хотя я так и не понял в чём же принципиальная разница между <>all(select...) и not exists(select...). оно как-то по разному обрабатывается сервером? и зачем тогда <>all :) - вроде как его всегда можно на not exists переписать . . .
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34896388
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LeXa NalBatпокажите лучше выдачу "EXPLAIN ANALYZE SELECT ..."
Andrey Daeron
..
На будующее - ВСЕГДА высылайте explain analyze для Вашего запроса. Это всегда хорошо, поскольку как минимум позволяет определить порядок количества записей в выборках. Без него - практически всегда - шаманство.
..


Если опытные товарищи говорят, что надо выслать план - высылайте...
теперь для обоих, пжл, любопытно )
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34896607
Фотография aov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вот 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 . . . в этом дело? и в чём разница между агрегатами этими? ну с нестед луп и мерге джойн яснее вроде - хотя тоже не оч. ну тут интуитивная есть догадка что джойн быстрее лупа должно быть :). как-то бы блин разобраться с этим на будущее....
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34896796
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Уважаемые Гуру.
Опишите, пжл, планы:
типа: сначало выполняется вложенные запрос, путем перебора всех записей..
Учусь читать планы PG, думаю, не мне одному будет интересно.
Спасибо
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34898154
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, может гуру поправят, но я понимаю это так:
Код: plaintext
1.
 -> 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)"

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.
 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.
словарик (гуру и не только - дополняйте, сам далеко не все знаю):
Seq Scan - тупой, последовательный чтений всех записей из таблицы с провркой (или без) условия
Index Scan -чтение данных из таблицы с использованием индексов (далее указывается условие для индекса)
Merge Join - слияние двух баличных представлений (таблиц, подселектов и т.д) методом merge - т.е. ИМХО тупого слияния.
GroupAggregate - аггрегирование по группам. Просто аггрегирование.
HashAggregate - Аггрегирование по построенному для каждой строки хешу (ИМХО лучше чем group, хотя чем - не знаю).

Дополняйте, подхватывайте, исправляйте - хороший ФАКовый вопрос получиццо.
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34898318
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 отсортированы
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34898559
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LeXa NalBat..план в выдаче EXPLAIN можно читать справа налево, то есть от наиболее глубоких этапов - к использующим их этапам.
..


в смысле снизу вверх?

и все таки, хотя бы один, плиз..
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34898652
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gold_ LeXa NalBatплан в выдаче EXPLAIN можно читать справа налево, то есть от наиболее глубоких этапов - к использующим их этапам.в смысле снизу вверх?нет, справа налево с уменьшением отступов. например запись
Код: plaintext
1.
2.
3.
4.
A
  B
    C
    D
  E
обозначает, что результаты этапов C и D идут на вход B, результаты B и E - на вход A, результат A - окончательный. то есть имеем древовидное представление.

Gold_и все таки, хотя бы один, плиз..В главе 13.1. Using EXPLAIN объясняются основные этапы. Там больше одного примера. :-)
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #34898966
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LeXa NalBat..нет, справа налево с уменьшением отступов. например запись
Код: plaintext
1.
2.
3.
4.
A
  B
    C
    D
  E
обозначает, что результаты этапов C и D идут на вход B, результаты B и E - на вход A, результат A - окончательный. то есть имеем древовидное представление.


Спасибо. То что нужно.
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #35106565
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LeXa NalBat... в "плановую" главу в книжке "Oracle Performance Tuning"...

А кто автор?
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #35107376
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #35120054
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
блин, нашел только на амазоне...
...
Рейтинг: 0 / 0
тормозит жостко запрос
    #35120132
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gold_блин, нашел только на амазоне...наверное можно что-нибудь поновее почитать. и я заглянул свежим взглядом в эту книжку - что-то не очень понравилось.
...
Рейтинг: 0 / 0
19 сообщений из 19, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / тормозит жостко запрос
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]