ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Почему планировщик сильно ошибается в оценке JOIN?
11 сообщений из 11, страница 1 из 1
Почему планировщик сильно ошибается в оценке JOIN?
    #39512984
Dany305
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dany305
Участник
Делаем джойн по двум таблицам.

План такой

Код: plaintext
1.
2.
Nested Loop  (cost=0.00..106.55 rows=1691 width=8) (actual rows=4 loops=1)
  ->  Append  (cost=0.00..81.17 rows=3 width=8) (actual rows=4 loops=1)
  ->  Append  (cost=0.00..8.44 rows=2 width=16) (actual rows=1 loops=4)

В одной таблице планировщик ожидает 3 записи, в другой 2,
а в джойне ему мерещится уже 1691 (!?).

Откуда это число? Разве максимально возможно число записей в джойне не 3*2?
...
Рейтинг: 0 / 0
30.08.2017, 18:26
| Ответить | Цитировать | Написать  
Почему планировщик сильно ошибается в оценке JOIN?
    #39512986
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Dany305Делаем джойн по двум таблицам.

План такой

Код: plaintext
1.
2.
Nested Loop  (cost=0.00..106.55 rows=1691 width=8) (actual rows=4 loops=1)
  ->  Append  (cost=0.00..81.17 rows=3 width=8) (actual rows=4 loops=1)
  ->  Append  (cost=0.00..8.44 rows=2 width=16) (actual rows=1 loops=4)

В одной таблице планировщик ожидает 3 записи, в другой 2,
а в джойне ему мерещится уже 1691 (!?).

Откуда это число? Разве максимально возможно число записей в джойне не 3*2?

Вы настолько обрезанный кусок плана дали что понять ничего нельзя.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
30.08.2017, 18:31
| Ответить | Цитировать | Написать  
Почему планировщик сильно ошибается в оценке JOIN?
    #39512990
Dany305
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dany305
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
QUERY PLAN
Nested Loop  (cost=0.00..106.55 rows=1691 width=8) (actual rows=4 loops=1)
  ->  Append  (cost=0.00..81.17 rows=3 width=8) (actual rows=4 loops=1)
        ->  Seq Scan on queries qq  (cost=0.00..0.00 rows=1 width=8) (actual rows=0 loops=1)
        ->  Index Scan using queries_2015_01_pkey on queries_2015_01 qq_1  (cost=0.43..81.17 rows=2 width=8) (actual rows=4 loops=1)
  ->  Append  (cost=0.00..8.44 rows=2 width=16) (actual rows=1 loops=4)
        ->  Seq Scan on bar (cost=0.00..0.00 rows=1 width=16) (actual rows=0 loops=4)
        ->  Index Scan using bar_2015_01_pkey on bar_2015_01 (cost=0.42..8.44 rows=1 width=16) (actual rows=1 loops=4)
...
Рейтинг: 0 / 0
30.08.2017, 18:41
| Ответить | Цитировать | Написать  
Почему планировщик сильно ошибается в оценке JOIN?
    #39513114
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexius
Участник
Dany305,

а как выглядит запрос и какая версия базы? используются ли какие-то экстеншны нестандартные?
...
Рейтинг: 0 / 0
31.08.2017, 06:55
| Ответить | Цитировать | Написать  
Почему планировщик сильно ошибается в оценке JOIN?
    #39513504
Dany305
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dany305
Участник
AlexiusDany305,

а как выглядит запрос и какая версия базы? используются ли какие-то экстеншны нестандартные?

Код: plsql
1.
2.
3.
4.
5.
6.
select b.bar_id
from queries q
join bar b on q.bar_id = b.bar_id      
where q.query_id = 91014
and q.query_time >= '2015-01-01 00:00:00'::timestamp and q.query_time < '2015-02-01 00:00:00'::timestamp
and b.bar_time >= '2015-01-01 00:00:00'::timestamp and b.bar_time < '2015-02-01 00:00:00'::timestamp



PostgreSQL 9.5.7

нестандартных экстеншенов нет
...
Рейтинг: 0 / 0
31.08.2017, 15:22
| Ответить | Цитировать | Написать  
Почему планировщик сильно ошибается в оценке JOIN?
    #39513576
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Dany305,

1691 -- чай простое, надо в коде искать битым текстом.
...
Рейтинг: 0 / 0
31.08.2017, 17:00
| Ответить | Цитировать | Написать  
Почему планировщик сильно ошибается в оценке JOIN?
    #39513586
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexius
Участник
Dany305,

хм, а точно план выше он от этого запроса и приведен без сокращений? primary key у вас по каким полям в обоих таблицах?
...
Рейтинг: 0 / 0
31.08.2017, 17:12
| Ответить | Цитировать | Написать  
Почему планировщик сильно ошибается в оценке JOIN?
    #39513591
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexius
Участник
и если сделать точно такой же запрос, но явно указать партиции, какой план получается?
...
Рейтинг: 0 / 0
31.08.2017, 17:18
| Ответить | Цитировать | Написать  
Почему планировщик сильно ошибается в оценке JOIN?
    #39513621
Dany305
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dany305
Участник
AlexiusDany305,

хм, а точно план выше он от этого запроса и приведен без сокращений? primary key у вас по каким полям в обоих таблицах?


query_id pk в query
bar_id pk в bar

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
QUERY PLAN
Nested Loop  (cost=0.00..25.38 rows=1127 width=8)
  ->  Append  (cost=0.00..8.46 rows=2 width=8)
        ->  Seq Scan on queries qq  (cost=0.00..0.00 rows=1 width=8)
              Filter: ((query_time >= 2015-01-01 00:00:00::timestamp without time zone) AND (query_time < 2015-02-01 00:00:00::timestamp without time zone) AND (query_id = 91014))
        ->  Index Scan using queries_2015_01_pkey on queries_2015_01 qq_1  (cost=0.43..8.46 rows=1 width=8)
              Index Cond: (query_id = 91014)
              Filter: ((query_time >= 2015-01-01 00:00:00::timestamp without time zone) AND (query_time < 2015-02-01 00:00:00::timestamp without time zone))
  ->  Append  (cost=0.00..8.44 rows=2 width=16)
        ->  Seq Scan on bar b  (cost=0.00..0.00 rows=1 width=16)
              Filter: ((bar_time >= 2015-01-01 00:00:00::timestamp without time zone) AND (bar_time < 2015-02-01 00:00:00::timestamp without time zone) AND (qq.bar_id = bar_id))
        ->  Index Scan using bar_2015_01_pkey on bar_2015_01 b_1  (cost=0.42..8.44 rows=1 width=16)
              Index Cond: (bar_id = qq.bar_id)
              Filter: ((bar_time >= 2015-01-01 00:00:00::timestamp without time zone) AND (bar_time < 2015-02-01 00:00:00::timestamp without time zone))

Alexiusи если сделать точно такой же запрос, но явно указать партиции, какой план получается?

если явно задавать партиции, то все хорошо))

Код: plaintext
1.
2.
QUERY PLAN
Nested Loop  (cost=0.85..16.91 rows=1 width=8) (actual rows=1 loops=1)
...
...
Рейтинг: 0 / 0
31.08.2017, 18:27
| Ответить | Цитировать | Написать  
Почему планировщик сильно ошибается в оценке JOIN?
    #39513658
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Dany305,

я думаю, оно на оппенд болт ложыд, а берет из статистики предка потолочную оценку.
рыбу заворачивали, какабычна.
...
Рейтинг: 0 / 0
31.08.2017, 19:38
| Ответить | Цитировать | Написать  
Почему планировщик сильно ошибается в оценке JOIN?
    #39513685
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexius
Участник
Dany305,

а сколько у вас всего партиций по каждой таблице? fk по bar_id между партициями разных таблиц нет?

как у вас в исходном плане получилось
Код: sql
1.
        ->  Index Scan using queries_2015_01_pkey on queries_2015_01 qq_1  (cost=0.43..81.17 rows=2 width=8) (actual rows=4 loops=1)



4 строки при выборке по pk? было другое условие в запросе, не query_id = x?

если сделать analyze queries; analyze bar; оценка не становится лучше?
...
Рейтинг: 0 / 0
31.08.2017, 20:35
| Ответить | Цитировать | Написать  
11 сообщений из 11, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Почему планировщик сильно ошибается в оценке JOIN?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&fpage=67&tid=1996249]:
 0ms
get settings:
 8ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 32ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 50ms
get tp. blocked users:
 2ms
others: 12ms
total:  139ms
созд. / загр.: 139ms
x
x
Закрыть


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