Re: bad plan using nested loops

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: bad plan using nested loops
Дата
Msg-id 23735.1517497241@sss.pgh.pa.us
обсуждение исходный текст
Ответ на bad plan using nested loops  (Johan Fredriksson <eskil@kth.se>)
Ответы SV: bad plan using nested loops  (Johan Fredriksson <eskil@kth.se>)
Список pgsql-performance
Johan Fredriksson <eskil@kth.se> writes:
> Bad plan: https://explain.depesz.com/s/avtZ
> Good plan: https://explain.depesz.com/s/SJSt
> Any suggestions on how to make the planner make better decisions for
> this query?

Core of the problem looks to be the misestimation here:

    Index Only Scan using shredder_cgm1 on public.cachedgroupmembers cachedgroupmembers_4 (cost=0.43..2.33 rows=79
width=8)(actual time=0.020..0.903 rows=1492 loops=804) 
      Output: cachedgroupmembers_4.memberid, cachedgroupmembers_4.groupid, cachedgroupmembers_4.disabled
      Index Cond: ((cachedgroupmembers_4.memberid = principals_1.id) AND (cachedgroupmembers_4.disabled = 0))
      Heap Fetches: 5018

Probably, memberid and disabled are correlated but the planner doesn't
know that, so it thinks the index condition is way more selective than it
actually is.  In PG 10, you could very possibly fix that by installing
extended statistics on that pair of columns.  See

https://www.postgresql.org/docs/current/static/planner-stats.html#PLANNER-STATS-EXTENDED

            regards, tom lane


В списке pgsql-performance по дате отправления:

Предыдущее
От: Nandakumar M
Дата:
Сообщение: Query optimiser is not using 'not null' constraint when 'order bynulls last' clause is used
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: effective_io_concurrency on EBS/gp2