Слишком оптимистичный LIMIT / PostgreSQL

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Слишком оптимистичный LIMIT

2 сообщений из 2, страница 1 из 1

Слишком оптимистичный LIMIT

#38953669

Nitro_Junkie

Участник

Сообщения: 935

Рейтинг: 0 / 0

Есть такой простой запрос:

Код: sql

1.
2.
3.
4.

SELECT t0.key0
FROM ZReport_receiptDetail t0
WHERE t0.ZReport_receiptReceiptDetail_ReceiptDetail=9426585
ORDER BY t0.key0 DESC LIMIT 19

При выполнении получаем такой, очевидно неправильный план:

Код: sql

1.
2.
3.
4.
5.
6.
7.

"Limit  (cost=0.43..622.60 rows=19 width=4) (actual time=1197.437..1197.573 rows=19 loops=1)"
"  Output: key0"
"  ->  Index Scan Backward using zreport_receiptdetail_pkey on public.zreport_receiptdetail t0  (cost=0.43..209017.54 rows=6383 width=4) (actual time=1197.435..1197.571 rows=19 loops=1)"
"        Output: key0"
"        Filter: (t0.zreport_receiptreceiptdetail_receiptdetail = 9426585)"
"        Rows Removed by Filter: 3472089"
"Total runtime: 1197.586 ms"

Меняю запрос на:

Код: sql

1.
2.
3.
4.

SELECT t0.key0
FROM ZReport_receiptDetail t0
WHERE t0.ZReport_receiptReceiptDetail_ReceiptDetail=9426585
ORDER BY t0.key0+2 DESC LIMIT 19

Получаю :

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

"Limit  (cost=1087.41..1087.46 rows=19 width=4) (actual time=1.570..1.571 rows=19 loops=1)"
"  Output: key0, ((key0 + 2))"
"  ->  Sort  (cost=1087.41..1103.37 rows=6383 width=4) (actual time=1.569..1.569 rows=19 loops=1)"
"        Output: key0, ((key0 + 2))"
"        Sort Key: ((t0.key0 + 2))"
"        Sort Method: top-N heapsort  Memory: 25kB"
"        ->  Index Scan using ddd on public.zreport_receiptdetail t0  (cost=0.43..919.92 rows=6383 width=4) (actual time=0.034..1.250 rows=4739 loops=1)"
"              Output: key0, (key0 + 2)"
"              Index Cond: (t0.zreport_receiptreceiptdetail_receiptdetail = 9426585)"
"Total runtime: 1.586 ms"

Собсно логику Postgres можно понять. Он берет cost получения всех записей 209017.54 делит на количество результирующих рядов 6383 и умножает на кол-во LIMIT 19 - и получает 622,6. При этом у плана с поиском всех receiptDetail с заданным значением, а потом упорядочивания cost 1000, то есть формально выше.

Но при этом проблема в том, что Postgres естественным образом не учитывает корелляцию (так как чеки проводятся порциями и номера чеков идут по возрастанию), и тем самым "плюет на дисперсию".

Как вообще можно бороться с такими случаями? Может есть какой-то способ увеличить cost при Limit'е (чтобы лучше работать в крайних случаях)?

...

Рейтинг:

0 / 0

07.05.2015, 15:09

| Ответить | Цитировать | Написать

Слишком оптимистичный LIMIT

#38953711

qwwq

Участник

Сообщения: 2 880

Рейтинг: 0 / 0

Nitro_Junkie,

как бороться -- вы сами уже успешно заборолись.

а если запросы часты --

Код: sql

CREATE INDEX  ON ZReport_receiptDetai (ZReport_receiptReceiptDetail_ReceiptDetail,key0)

-- оно вам заборет сканирование всего индекса при плохой корреляции

...

Рейтинг:

0 / 0

07.05.2015, 15:35

| Ответить | Цитировать | Написать

2 сообщений из 2, страница 1 из 1

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Слишком оптимистичный LIMIT

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=53&gotonew=1&tid=1998004]:	0ms
get settings:	8ms
get forum list:	18ms
check forum access:	3ms
check topic access:	3ms
track hit:	29ms
get topic data:	8ms
get first new msg:	5ms
get forum data:	2ms
get page messages:	32ms
get tp. blocked users:	1ms
others:	215ms

total:	324ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы