|
медленный index scan + limit
|
|||
---|---|---|---|
#18+
fteDany305, Dany305для обычных таблиц эти значения близки и особой разницы нет, но для очередей это не так а эта таблица работает как очередь - интенсивно лопатиться, но живых записей мало после analyze в reltuples запишется маленькое число и планировщик будет выбирать быстрый seq scan после vacuum в reltuples запишется большое число и планировщик будет выбирать медленный index scan +1 ИМНО: индивидуальные(агрессивные) настройки autovacuum для таблицы должны помочь... вряд ли помогут в решение данной проблемы, кажется не существует настроек autovacuum, которые бы гарантировали порядок исполнения: vacuum, analyze в сходной проблеме мне помогло выключение autovacuum + ручной vacuum analyze ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2017, 20:30 |
|
медленный index scan + limit
|
|||
---|---|---|---|
#18+
Dany305, тут же всё расписано : //думается кост из инд-скана не берется, а берется из лимита (т.к. ре--сорта нет) если это не так -- они ещё тупее, чем я думайу kukurzik ... дело в селективности, при определенном пороге пж переключается с правильного индекса (клиент, ид) на "неправильный"(ид) Код: sql 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. 31. 32. 33. 34. 35. 36. 37. 38.
за счет чего так просела стоимость лимита по пк -- не ясно. неужели за счет одной лишь ширины инлекса ? на 50 записей доступов д.б. с гулькин нос (по спецу). а в пк же множитель 100/7 как минимум д.б. в костах ? с какого потолка он 51.22 высосал ? или кост этих 100/7 ещё где--то отдельно написан ? -- судя по всему -- там все херово даже с арифметикой. или пусть кто--то разъяснит, как стоимость лимита вдоль выборки (без ресорта) расписана в плане . не собирается же он сначала выфетчить унутре в себя те самые 1438, по цене 5557.34 Код: plaintext
(на кой хер там вообще эта цифра ?или стюдент 100 лет тому написал -- и хай буде ?) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2017, 20:32 |
|
медленный index scan + limit
|
|||
---|---|---|---|
#18+
qwwqили пусть кто--то разъяснит, как стоимость лимита вдоль выборки (без ресорта) расписана в плане . не собирается же он сначала выфетчить унутре в себя те самые 1438, по цене 5557.34 Код: plaintext
Ну вот потому и считается оценка как 2 числа: цена вывода первых записей в узле и цена на всю работу узла. Собственно, цена вывода первых записей (первая цена) и используется в случаях с LIMIT. Как оно оценивается для LIMIT 1 и/или LIMIT 50 я точно не скажу, надо в исходники лезть. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2017, 20:51 |
|
медленный index scan + limit
|
|||
---|---|---|---|
#18+
вдогонку: из 2-х индексов not unique (id) , unique (id,indexed) при линковке по id и без выборки поля "индексед" планер выбирает составной уникъю. (при неуникальности ид в десятые процента) Вангую -- он может прикинуть ограничение количество ид по нему. и насчитать плану меньший кост. а что это количество ограничено для всей таблы (может быть разнесено на прочие оценки) -- то пусть лошадь думает. И пусть сама связывает факт с более компактным не уникъю. забавно. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2018, 14:53 |
|
медленный index scan + limit
|
|||
---|---|---|---|
#18+
qwwqвдогонку: из 2-х индексов not unique (id) , unique (id,indexed) при линковке по id и без выборки поля "индексед" планер выбирает составной уникъю. (при неуникальности ид в десятые процента) Вангую -- он может прикинуть ограничение количество ид по нему. и насчитать плану меньший кост. а что это количество ограничено для всей таблы (может быть разнесено на прочие оценки) -- то пусть лошадь думает. И пусть сама связывает факт с более компактным не уникъю. забавно. а индекс по id точно более компактный (если \di+ indexname cравнить) ? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2018, 16:56 |
|
медленный index scan + limit
|
|||
---|---|---|---|
#18+
Alexiusа индекс по id точно более компактный (если \di+ indexname cравнить) ? их у меня 90 штук. т.ч. какие-то точно компактнее. вернее на паре кейсов отреиндексил (ещё тогда) оба -- поведение не изменилось. отпишусь позже -- сейчас дисковую нагрузил замером. и да, пж умеет извлекать из уникальности поправки к планам и костам (по лейтералам из пк видно -- планирует по 1). но кажется не умеет обобществлять общезначимые следствия из. (так же как выше по теме получая лучший план из недостаточной модели (равновероятности неизвестного)-- пренебрегает "худшим" из точного индекса-- отбросить дурной оптимистический план, который де-факто д.б. зарезан планом по верному индексу он не умеет) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2018, 17:27 |
|
медленный index scan + limit
|
|||
---|---|---|---|
#18+
Alexius, сделал Код: sql 1.
переиндексировал (чтобы без дырок) и аналайзнул. появились сканы по узкому инд-у. но остались и по широкому (если записей в плане мало). Код: sql 1. 2. 3. 4. 5.
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
--тут по уникъю планируется drop UNIQUE: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
и , при массовом плане от 2--5% ожидаемо падаем в хеш Код: sql 1. 2. 3. 4. 5. 6.
при таргете в 500 все было либо хешем, либо по уникъю. откачусь. там интереснее. если поймаю разницу в планах по ожиданиям -- отпишусь. пока же резюме -- при равных костах предпочитается уникъю, даже если шире. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2018, 10:41 |
|
|
start [/forum/topic.php?fid=53&msg=39618932&tid=1995875]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
others: | 284ms |
total: | 412ms |
0 / 0 |