powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / почему seqscan?
16 сообщений из 16, страница 1 из 1
почему seqscan?
    #35117674
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PG8.2.5 Ubuntu. Памяти 4Гб, raid5 5x15K

таблицы, связанны FK на INT4, все поля, по которым происходит объединение имеют индексы.
Откуда берутся такие ошибки в планировщике:
start-up cost =570
total cost = 6000 ?

После facuum full, analyze, reindex. Без изменений

Код: plaintext
1.
2.
3.
4.
5.
select SA.articleid, SA.code, SA.name, PLI.Price,SRP.SaleRankID
from PricelistItems as PLI --80K records
inner join salearticles as SA on (PLI.SaleArticleID = SA.SaleArticleID) --15K records
inner join PriceLists as PL on (PL.PriceListID = PLI.PriceListID) --7 records
inner join SaleRankPrices as SRP on (SRP.PriceListID = PL.PriceListID)  --7 records

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Hash Join  (cost=570.63..5157.34 rows=72683 width=62) (actual time=65.336..861.398 
rows=72712 loops=1)
  Hash Cond: ((pli.salearticleid)::integer = (sa.salearticleid)::integer)
  ->  Hash Join  (cost=2.41..2408.63 rows=72683 width=17) (actual time=0.149..403.109 rows=72712 loops=1)
        Hash Cond: ((pli.pricelistid)::integer = (pl.pricelistid)::integer)
        ->  Seq Scan on pricelistitems pli  (cost=0.00..1406.83 rows=72683 width=17) (actual time=0.015..128.372 rows=72712 loops=1)
        ->  Hash  (cost=2.32..2.32 rows=7 width=12) (actual time=0.118..0.118 rows=7 loops=1)
              ->  Hash Join  (cost=1.16..2.32 rows=7 width=12) (actual time=0.061..0.099 rows=7 loops=1)
                    Hash Cond: ((pl.pricelistid)::integer = (srp.pricelistid)::integer)
                    ->  Seq Scan on pricelists pl  (cost=0.00..1.07 rows=7 width=4) (actual time=0.004..0.016 rows=7 loops=1)
                    ->  Hash  (cost=1.07..1.07 rows=7 width=8) (actual time=0.041..0.041 rows=7 loops=1)
                          ->  Seq Scan on salerankprices srp  (cost=0.00..1.07 rows=7 width=8) (actual time=0.006..0.019 rows=7 loops=1)
  ->  Hash  (cost=369.21..369.21 rows=15921 width=53) (actual time=65.132..65.132 rows=15921 loops=1)
        ->  Seq Scan on salearticles sa  (cost=0.00..369.21 rows=15921 width=53) (actual time=0.011..31.127 rows=15921 loops=1)
Total runtime: 978.464 ms
...
Рейтинг: 0 / 0
почему seqscan?
    #35117815
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что-то я не понял где Вы увидели ошибки планировщика.
ИМХО план соответсвует тому что Вы запросили у Постгреса.
PLI (80К) стыкуется с 2 мелкими справочниками и одной толстой таблицы.
Оптять же 72683 строк по 62юайта - это ~4М результата. А первую строчку Вы получите практически мгновенно 65мсек.

Можете попробовать отключить seq_scan, но не думаю, чтоэто поможет.
...
Рейтинг: 0 / 0
почему seqscan?
    #35118310
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
за секунду перемолотил 70 тыс строк - наверное это ок?

в чем ошибка - в том что выбрал seqscan?

или ошибка в подсчете cost=570.63..5157.34?
...
Рейтинг: 0 / 0
почему seqscan?
    #35118383
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeXa NalBat
в чем ошибка - в том что выбрал seqscan?
или ошибка в подсчете cost=570.63..5157.34?
Ошибка, IMHO, в подсчете.
Никогда не видел такой большой разницы.

Я неверно тему сформулировал. Именно SeqScan и должен быть, раз берут всю таблицу.
Верно?
...
Рейтинг: 0 / 0
почему seqscan?
    #35118722
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tadmin LeXa NalBat
в чем ошибка - в том что выбрал seqscan?
или ошибка в подсчете cost=570.63..5157.34?
Ошибка, IMHO, в подсчете.
Никогда не видел такой большой разницы.

570 - это время первой строки, оно действительно небольшое, но потом нужно "поднять" всю таблицу на 70 тыс строк, а закончится это нескоро.
tadmin
Я неверно тему сформулировал. Именно SeqScan и должен быть, раз берут всю таблицу.
Верно?
По крайней мере очень похоже на правду. :)

PS Может меня LeXa NalBat поправит и дополнит, но бывают две ошибки оптимизатора:
1. Ошибка оценки количества строк. Это выглядит как большая разница между строками explain и строками explain analyze. Как следствие - неправильный план выполнения запроса.
2. Просто неправильно выбранный план. Это сложно диагностируемая ошибка, обычно обнаруживатеся по тому, что запрос "тормозит", и вроде как есть представление о том, как по другому можно написать план выполнения запроса.

И есть еще несколько распространённых случаев:
1. Ошибка разработчика SQL, когда он пишет, мягко скажем, неоптимальный запрос, который СУБД не может переколбасить его во что-то более приличное.
2. Отсутствие в СУБД некторых "фич" (обычно идёт вопрос "А у меня в ххх работает в 100 раз быстрее!"
...
Рейтинг: 0 / 0
почему seqscan?
    #35118855
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
всем спасибо,
похоже все в порядке, я лишь неверно интерпертирую план запроса.
...
Рейтинг: 0 / 0
почему seqscan?
    #35118891
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrey Daeron tadminОшибка, IMHO, в подсчете.
Никогда не видел такой большой разницы.570 - это время первой строки, оно действительно небольшое, но потом нужно "поднять" всю таблицу на 70 тыс строк, а закончится это нескоро.да. причем время выдачи первой строки 570 не близко к нулю, потому что перед выдачей первой строки надо полностью построить хэш в 16 тыс строк salearticles

Andrey Daeron tadminЯ неверно тему сформулировал. Именно SeqScan и должен быть, раз берут всю таблицу.
Верно?По крайней мере очень похоже на правду. :)да, план хороший

PS

по оценкам планировщика не все понятно. может кто-нибудь объяснит?

Код: plaintext
1.
2.
3.
Hash Join  (cost=570.63..5157.34) (actual time=65.336..861.398)
  ->  Hash Join  (cost=2.41..2408.63) (actual time=0.149..403.109)
  ->  Hash  (cost=369.21..369.21) (actual time=65.132..65.132)
        ->  Seq Scan (cost=0.00..369.21) (actual time=0.011..31.127)

почему планировщик считает, что на построение hash вообще не тратися времени по сравнению с seqscan: cost 369.21 == 369.21? хотя на самом деле таблица сканируется за time 31.127, а хэш строится за 65.132.

почему планировщик считает, что первая строка от Hash Join будет возвращена через cost 570.63, должно быть наверное: цена построения хэша cost 369.21 плюс еще чуть-чуть - откуда разница в 200? в реальном времени наблюдаем: time 65.132 ~= 65.336.
...
Рейтинг: 0 / 0
почему seqscan?
    #35119518
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LeXa NalBat

почему планировщик считает, что на построение hash вообще не тратися времени по сравнению с seqscan: cost 369.21 == 369.21? хотя на самом деле таблица сканируется за time 31.127, а хэш строится за 65.132.



cpu_operator_cost такого поведения нельзя "добиться"?
...
Рейтинг: 0 / 0
почему seqscan?
    #35119753
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Gold_
cpu_operator_cost такого поведения нельзя "добиться"?

Был не прав. Параметры влияющие на стоимость запрооса не трогал. Стоимость на hash не считается. постгрес 7.4.1
...
Рейтинг: 0 / 0
почему seqscan?
    #35119866
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не поясните ли, в чем измеряется "cost" ?

Вероятно эти попугаи сложно связаны связаны с реальным временем через доступные IOPS для подъема страниц, циклы CPU и т.д.
PGDOCS, по-моему, никак не трактуют их размерность
Есть где-нибудь рассуждения на эту тему в общем смысле?
...
Рейтинг: 0 / 0
почему seqscan?
    #35120016
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tadminНе поясните ли, в чем измеряется "cost" ? 14.1. Using EXPLAIN

The costs are measured in arbitrary units determined by the planner's cost parameters (see Section 18.6.2). Traditional practice is to measure the costs in units of disk page fetches; that is, seq_page_cost is conventionally set to 1.0 and the other cost parameters are set relative to that.

tadminВероятно эти попугаи сложно связаны связаны с реальным временем через доступные IOPS для подъема страниц, циклы CPU и т.д.наоборот. вы сами можете провести тестирование производительности своего железа на операциях аналогичных seq_page, random_page, cpu_tuple, cpu_index_tuple, cpu_operator, и установить в конфиге значения random_page_cost, cpu_tuple_cost, cpu_index_tuple_cost, cpu_operator_cost в соответствии с результатами ваших экспериментов, например приняв за единицу seq_page_cost=1.
...
Рейтинг: 0 / 0
почему seqscan?
    #35121800
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeXa NalBat
tadminВероятно эти попугаи сложно связаны связаны с реальным временем через доступные IOPS для подъема страниц, циклы CPU и т.д.наоборот. вы сами можете провести тестирование производительности своего железа на операциях аналогичных seq_page, random_page, cpu_tuple, cpu_index_tuple, cpu_operator, и установить в конфиге значения random_page_cost, cpu_tuple_cost, cpu_index_tuple_cost, cpu_operator_cost в соответствии с результатами ваших экспериментов, например приняв за единицу seq_page_cost=1.

А как это сделать на практике?
...
Рейтинг: 0 / 0
почему seqscan?
    #35123421
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrey Daeron LeXa NalBatвы сами можете провести тестирование производительности своего железа на операциях аналогичных seq_page, random_page, cpu_tuple, cpu_index_tuple, cpu_operator, и установить в конфиге значения random_page_cost, cpu_tuple_cost, cpu_index_tuple_cost, cpu_operator_cost в соответствии с результатами ваших экспериментовА как это сделать на практике?имхо, если бы кто-нибудь это знал, то в постгрес добавили бы утилитку для бенчмарка железа, автоматически подстраивающую эти параметры в конфиге. я примерно год назад читал, что разработчики хотели сделать такую утилиту, но видимо пока не сделали.

наверное эти настройки надо выбирать не только основываясь на технических характеристиках компа, но и на задачах, которые будут решаться. например мы пытались тюнить эти параметры учитывая, что в нашей задаче часто используемые данные влезают в кэш оперативной памяти, запросы только на выборку, то есть жесткий диск почти не дергается.

изменяя эти параметры, мы пытались добиться того, чтобы для типичных в нашей задаче запросов постгрес правильно оценивал cost, то есть чтобы cost было пропорционально real time. в итоге выбрали значение random_page_cost=2, остальные оставили по дефолту.
...
Рейтинг: 0 / 0
почему seqscan?
    #35123706
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeXa NalBat Andrey Daeron LeXa NalBatвы сами можете провести тестирование производительности своего железа на операциях аналогичных seq_page, random_page, cpu_tuple, cpu_index_tuple, cpu_operator, и установить в конфиге значения random_page_cost, cpu_tuple_cost, cpu_index_tuple_cost, cpu_operator_cost в соответствии с результатами ваших экспериментовА как это сделать на практике?имхо, если бы кто-нибудь это знал, то в постгрес добавили бы утилитку для бенчмарка железа, автоматически подстраивающую эти параметры в конфиге. я примерно год назад читал, что разработчики хотели сделать такую утилиту, но видимо пока не сделали.

Т.е. на практике обычным сметрным провести тестирование производительности своего железа - нереально, можно только методом псевдонаучного тыка, по критерию приближения стоимости cost к реал-тайм (с каким-то коэффициентом-множителем) на большинстве запросов.
...
Рейтинг: 0 / 0
почему seqscan?
    #35124675
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrey DaeronТ.е. на практике обычным сметрным провести тестирование производительности своего железа - нереально, можно только методом псевдонаучного тыканаверное да, нам, "обычным сметрным", остается или методом тыка, или превращаться в "бессмертных" :-) и курить сорцы, придумывать тесты для железа и софта, и т.д.
...
Рейтинг: 0 / 0
почему seqscan?
    #35125029
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мне кажется (теоретизирую), что на уровнях:
- CPU cache
- file block
- RAID block
должен быть заметный эффект от настройки этих параметров.
Мешает делу то, что на всех этих уровнях есть либо прямые помехи для таких измерений (CPU cache - многозадачность), либо сглаживающие факторы (RAID cache, OS FS cache).
В результате, если крутить эти параметры без реального представления об их смысле, то железо будет в широких пределах исправлять дурость экспериментатора.

Подкрутили вниз, скажем, параметр цены подъема страницы с диска, а скорость не упала, оценка планировщика тоже в порядке. Не факт, что вы не на что не повлияли.

Если RAID хранилище имеет большой кеш и read-ahead настройку, то железо уже зафетчило данные и оттранслировать их в OS кеш копейки стоит.

Т.е. на мощном железе приходится крутить настройки слишком далеко, прежде чем увидишь результат. А при таких перекосах уже непонятно, во что ты уперся.
Темный лес.
...
Рейтинг: 0 / 0
16 сообщений из 16, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / почему seqscan?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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