> Имею в виду — получите близкий к правдоподобному план

и им и занимайтесь.

В чём измерять близость к правдоподобию? я этот топик начал с того что хочу получить "близкий" к правдоподобию запрос

> Вы думаете, что он будет существенно другим, чем правильный? А почему?
Это же можно сказать, если хотя бы на какие-то планы посмотреть...

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

> Да из плана же! Может, он совершенно не оптимален, и "танцевать" вокруг него с точными измерениями I/O просто не нужно?

я не имею обширного опыта, но иду обычно по цене или времени узла. если время и цена узла меня полностью устраивает в существующих "правильных" планах запроса. каким образом требуется определять неоптимальность? увы план не могу выложить, там может проскочить ПД (ну только если затирать)

> Они будут отталкиваться от того, что я увижу в плане.

Всё тот же аргумент, цена и время в имеющихся планах меня устраивает.

> В чём измерять близость к правдоподобию? Это, опять-таки, можно увидеть по плану. Может быть, планирование этого запроса очевидно чувствительно к значениям параметров? А может, там читается так мало buffers, что такой проблемы в этом просто не может быть? И т.д. и т.п. > я вижу дерево которое выполняется за десятки миллисекунд. Показали бы Вы план уже, что ли... ;) > но иду обычно по цене или времени узла. И всё это при оптимизации запросов зачастую практически неважно. Вот точность оценок и buffers hit/read обычно куда интереснее. > увы план не могу выложить, там может проскочить ПД На https://explain.depesz.com/ есть: "I want this plan to be obfuscated before saving. (Note that this makes plans much harder to understand for others, so use only when absolutely necessary.)" > Всё тот же аргумент, цена и время в имеющихся планах меня устраивает. Может быть, в них не так что-то другое, см. выше.

Кстати, пока с вами обсуждали я смог поймать более менее "близкий" к долгому запрос. План с лёгкой просадкой: https://explain.depesz.com/s/oVgm каким план предстаёт в 95% https://explain.depesz.com/s/UKiQ

План, по сути, тот же. И buffers используется там мало. А проблема была в чём, конкретно (насколько он тормозил)? А индекс Вы этот подозревали? -> Index Scan using victor_two on victor_india oscar (cost=0.56..2.79 rows=1 width=156) (actual time=6.153..6.154 rows=1 loops=1) Index Cond: (((alpha)::text = 'uniform_charlie'::text) AND (golf_four = 2) AND (yankee_mike = 1) AND (papa = 1)) Buffers: shared hit=2 read=3 dirtied=1 I/O Timings: read=5.983 т.е. это ожидаемо?

Да подозреваю этот индекс. он часть индекса партиционированной таблицы. на индексах этой таблицы достаточно много read (относительно других таблиц в кластере) Тормозить может до 5 секунд, если верить pg_stat_statements

> Тормозить может до 5 секунд, если верить pg_stat_statements А ведь не должно такого быть, казалось бы. Т.е. 5 секунд на чтение, грубо, 0.5Мб как-то многовато (что это за диск), нет? Т.е. либо с ним что-то не так, либо есть мешающая конкурентная нагрузка (блокировки с каким-то DDL, может быть? Или locks временами не хватает, если там много partitions?). Тем не менее, допустим даже, что он "не виноват". Тогда придётся либо снижать размер читаемого, либо давать больше памяти, опять-таки.

Это виртуалка в openstak под ногами скорее всего hdd. Увы в сторону дисков меня толкали показатели pg_stat_statments где от total_time времени выполнения до 60% доходило время blk_read_time с дисков.

> Это виртуалка в openstak под ногами скорее всего hdd. Понятно. Тогда может быть, в принципе. > до 60% доходило время blk_read_time с дисков. Ну да, это намекает. ;) По мониторингу остального уже подсказали, вроде бы... > пики дисков не совпдают с пиками задержек. Да, это несколько странно, но тоже может быть. В любом случает, в плане поиска решения пути всё те же.

А на что подозревают индекс? На "разбухание"? И как понять, что должно быть ожидаемо?)

Если я правильно понял, то на "случайные" чтения. Т.е. доступ происходит почти ко всем страницам индекса, а не локализуется, как чаще всего бывает.