powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / по плану запроса после сортировки увеличилось количество записей
7 сообщений из 7, страница 1 из 1
по плану запроса после сортировки увеличилось количество записей
    #35123815
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
по плану запроса после сортировки увеличилось количество записей. Часть плана:
Код: plaintext
1.
2.
       ->  Sort  (cost= 19977 . 42 .. 20380 . 08  rows= 161063  width= 8 ) (actual time= 535 . 948 .. 717 . 975  rows= 284891  loops= 1 )
               Sort Key: dreg.kod_dok
               ->  Seq Scan on tdok_reg dreg  (cost= 0 . 00 .. 4537 . 63  rows= 161063  width= 8 ) (actual time= 0 . 014 .. 140 . 947  rows= 161063  loops= 1 )
Пострес 7.4.1
Как такое может произойти??
...
Рейтинг: 0 / 0
по плану запроса после сортировки увеличилось количество записей
    #35124496
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gold_по плану запроса после сортировки увеличилось количество записей. Часть планачудеса конечно. а можете показать целиком explain и запрос?
...
Рейтинг: 0 / 0
по плану запроса после сортировки увеличилось количество записей
    #35124776
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
"Урезанный" запрос:
Код: plaintext
1.
2.
3.
4.
EXPLAIN ANALYZE
SELECT *
FROM dok.tdok_main dmain 
INNER JOIN dok.tdok_reg dreg ON ( dmain.kod_dok =dreg.kod_dok )
INNER JOIN tsk.ttsk_dok tdok ON ( dmain.kod_dok =tdok.kod_dok ) 

и план запроса

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Merge Join  (cost= 40593 . 74 .. 50223 . 57  rows= 302816  width= 882 ) (actual time= 2552 . 224 .. 9369 . 504  rows= 284243  loops= 1 )
  Merge Cond: ("outer".kod_dok = "inner".kod_dok)
  ->  Merge Join  (cost= 16645 . 59 .. 21792 . 47  rows= 89526  width= 770 ) (actual time= 727 . 336 .. 2446 . 527  rows= 89499  loops= 1 )
        Merge Cond: ("outer".kod_dok = "inner".kod_dok)
        ->  Index Scan using fki_ttsk_dok_tdok_main on ttsk_dok tdok  (cost= 0 . 00 .. 3580 . 31  rows= 89499  width= 18 ) (actual time= 0 . 073 .. 260 . 168  rows= 89499  loops= 1 )
        ->  Sort  (cost= 16645 . 59 .. 16772 . 40  rows= 50727  width= 752 ) (actual time= 727 . 188 .. 928 . 005  rows= 91385  loops= 1 )
              Sort Key: dmain.kod_dok
              ->  Append  (cost= 0 . 00 .. 2298 . 27  rows= 50727  width= 752 ) (actual time= 0 . 030 .. 174 . 570  rows= 50727  loops= 1 )
                    ->  Seq Scan on tdok_main dmain  (cost= 0 . 00 .. 2297 . 12  rows= 50712  width= 261 ) (actual time= 0 . 028 .. 105 . 291  rows= 50712  loops= 1 )
                    ->  Seq Scan on tdokd_pers dmain  (cost= 0 . 00 .. 1 . 15  rows= 15  width= 752 ) (actual time= 0 . 054 .. 0 . 155  rows= 15  loops= 1 )
  ->  Sort  (cost= 23948 . 15 .. 24350 . 81  rows= 161063  width= 112 ) (actual time= 1824 . 801 .. 2260 . 912  rows= 284891  loops= 1 )
        Sort Key: dreg.kod_dok
        ->  Seq Scan on tdok_reg dreg  (cost= 0 . 00 .. 4537 . 63  rows= 161063  width= 112 ) (actual time= 0 . 058 .. 251 . 894  rows= 161063  loops= 1 )
Total runtime:  11346 . 713  ms

...
Рейтинг: 0 / 0
по плану запроса после сортировки увеличилось количество записей
    #35124914
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в запросе не видно обращения к tdokd_pers, который присутствует в плане. почему так?

приведите пожалуйста выдачу
explain analyze select * from dok.tdok_main dmain;
explain analyze select * from dok.tdok_main dmain order by dmain.kod_dok;

и сколько реально строк возвращают запросы
select * from dok.tdok_main dmain;
select * from dok.tdok_main dmain order by dmain.kod_dok;
...
Рейтинг: 0 / 0
по плану запроса после сортировки увеличилось количество записей
    #35125036
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LeXa NalBatв запросе не видно обращения к tdokd_pers, который присутствует в плане. почему так?

tdokd_pers - наследник dok.tdok_main
LeXa NalBat
приведите пожалуйста выдачу
explain analyze select * from dok.tdok_main dmain;
explain analyze select * from dok.tdok_main dmain order by dmain.kod_dok;

explain analyze select * from dok.tdok_main dmain;
Код: plaintext
1.
2.
3.
4.
5.
Result  (cost= 0 . 00 .. 2298 . 27  rows= 50727  width= 752 ) (actual time= 0 . 058 .. 737 . 613  rows= 50727  loops= 1 )
  ->  Append  (cost= 0 . 00 .. 2298 . 27  rows= 50727  width= 752 ) (actual time= 0 . 041 .. 169 . 596  rows= 50727  loops= 1 )
        ->  Seq Scan on tdok_main dmain  (cost= 0 . 00 .. 2297 . 12  rows= 50712  width= 261 ) (actual time= 0 . 040 .. 104 . 449  rows= 50712  loops= 1 )
        ->  Seq Scan on tdokd_pers dmain  (cost= 0 . 00 .. 1 . 15  rows= 15  width= 752 ) (actual time= 0 . 057 .. 0 . 146  rows= 15  loops= 1 )
Total runtime:  770 . 643  ms

explain analyze select * from dok.tdok_main dmain order by dmain.kod_dok;

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Sort  (cost= 16645 . 59 .. 16772 . 40  rows= 50727  width= 752 ) (actual time= 1280 . 066 .. 1385 . 386  rows= 50727  loops= 1 )
  Sort Key: dmain.kod_dok
  ->  Result  (cost= 0 . 00 .. 2298 . 27  rows= 50727  width= 752 ) (actual time= 0 . 030 .. 704 . 346  rows= 50727  loops= 1 )
        ->  Append  (cost= 0 . 00 .. 2298 . 27  rows= 50727  width= 752 ) (actual time= 0 . 010 .. 135 . 877  rows= 50727  loops= 1 )
              ->  Seq Scan on tdok_main dmain  (cost= 0 . 00 .. 2297 . 12  rows= 50712  width= 261 ) (actual time= 0 . 007 .. 71 . 977  rows= 50712  loops= 1 )
              ->  Seq Scan on tdokd_pers dmain  (cost= 0 . 00 .. 1 . 15  rows= 15  width= 752 ) (actual time= 0 . 020 .. 0 . 247  rows= 15  loops= 1 )
Total runtime:  2156 . 705  ms

LeXa NalBat
и сколько реально строк возвращают запросы
select * from dok.tdok_main dmain;
select * from dok.tdok_main dmain order by dmain.kod_dok;

оба запроса 50727
...
Рейтинг: 0 / 0
по плану запроса после сортировки увеличилось количество записей
    #35125149
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
наблюдается то же самое на 8.1. видимо наличие Merge Join влияет на actual rows в Sort. может быть оно обозначает кол-во строк, которое отдает этап Sort, а из-за дублирования значений в ключе по которому идет соединение, Join берет одну и ту же строку от Sort несколько раз. причем в нижеследующем примере для inner join кол-во строк увеличивается с 20 до 31, а для outer join - до 40.

Код: plaintext
1.
2.
3.
create table t1 as select generate_series(  3 ,  32  )/ 3  as id;
create table t2 as select generate_series(  12 ,  31  )/ 2  as id;
explain analyze select * from t1 natural join t2;
explain analyze select * from t1 natural full join t2;

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
nalbat=> create table t1 as select generate_series(  3 ,  32  )/ 3  as id;
SELECT
nalbat=> create table t2 as select generate_series(  12 ,  31  )/ 2  as id;
SELECT
nalbat=> explain analyze select * from t1 natural join t2;
                                                 QUERY PLAN
-------------------------------------------------------------------------------------------------------------
 Merge Join  (cost= 299 . 56 .. 653 . 73  rows= 22898  width= 4 ) (actual time= 0 . 335 .. 0 . 592  rows= 30  loops= 1 )
   Merge Cond: ("outer".id = "inner".id)
   ->  Sort  (cost= 149 . 78 .. 155 . 13  rows= 2140  width= 4 ) (actual time= 0 . 157 .. 0 . 225  rows= 30  loops= 1 )
         Sort Key: t1.id
         ->  Seq Scan on t1  (cost= 0 . 00 .. 31 . 40  rows= 2140  width= 4 ) (actual time= 0 . 006 .. 0 . 079  rows= 30  loops= 1 )
   ->  Sort  (cost= 149 . 78 .. 155 . 13  rows= 2140  width= 4 ) (actual time= 0 . 103 .. 0 . 164  rows= 31  loops= 1 )
         Sort Key: t2.id
         ->  Seq Scan on t2  (cost= 0 . 00 .. 31 . 40  rows= 2140  width= 4 ) (actual time= 0 . 004 .. 0 . 048  rows= 20  loops= 1 )
 Total runtime:  0 . 702  ms
( 9  rows)

nalbat=> explain analyze select * from t1 natural full join t2;
                                                 QUERY PLAN
-------------------------------------------------------------------------------------------------------------
 Merge Full Join  (cost= 299 . 56 .. 653 . 73  rows= 22898  width= 8 ) (actual time= 0 . 273 .. 0 . 698  rows= 55  loops= 1 )
   Merge Cond: ("outer".id = "inner".id)
   ->  Sort  (cost= 149 . 78 .. 155 . 13  rows= 2140  width= 4 ) (actual time= 0 . 159 .. 0 . 221  rows= 30  loops= 1 )
         Sort Key: t1.id
         ->  Seq Scan on t1  (cost= 0 . 00 .. 31 . 40  rows= 2140  width= 4 ) (actual time= 0 . 008 .. 0 . 077  rows= 30  loops= 1 )
   ->  Sort  (cost= 149 . 78 .. 155 . 13  rows= 2140  width= 4 ) (actual time= 0 . 104 .. 0 . 189  rows= 40  loops= 1 )
         Sort Key: t2.id
         ->  Seq Scan on t2  (cost= 0 . 00 .. 31 . 40  rows= 2140  width= 4 ) (actual time= 0 . 004 .. 0 . 050  rows= 20  loops= 1 )
 Total runtime:  0 . 863  ms
( 9  rows)
...
Рейтинг: 0 / 0
по плану запроса после сортировки увеличилось количество записей
    #35125291
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LeXa NalBat
огромное спасибо.
...
Рейтинг: 0 / 0
7 сообщений из 7, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / по плану запроса после сортировки увеличилось количество записей
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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