Re: Problem with performance using query with unnest after migrating from V9.1 to V9.2 and higher

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Problem with performance using query with unnest after migrating from V9.1 to V9.2 and higher
Дата
Msg-id 15768.1474554930@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Problem with performance using query with unnest after migrating from V9.1 to V9.2 and higher  (Igor Neyman <ineyman@perceptron.com>)
Список pgsql-performance
Igor Neyman <ineyman@perceptron.com> writes:
> table_a is too small, just 50 records.
> Optimizer decided (correctly) that Seq Scan is cheaper than using an index.

Yeah.  The given test case is quite useless for demonstrating that you
have a problem, since it's actually *faster* on 9.5 than 9.1.

What I suspect is happening is that 9.2 and up assume that an unnest()
will produce 100 rows, whereas 9.1 assumed it would produce only 1 row.
The latter happened to be more accurate for this specific case, though
in general it could result in selection of very bad plans.

If you are intending only one value be selected, don't use unnest();
you'd be better off with "(string_to_array('5010010000',','))[1]"
or something like that.

In the long run we should teach the planner how to produce better
estimates for unnest-on-a-constant-array, though I'm unsure whether
that would help your real application as opposed to this test case.

            regards, tom lane


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

Предыдущее
От: Igor Neyman
Дата:
Сообщение: Re: Multiple-Table-Spanning Joins with ORs in WHERE Clause
Следующее
От: Igor Neyman
Дата:
Сообщение: Re: Multiple-Table-Spanning Joins with ORs in WHERE Clause