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

From Tom Lane
Subject Re: Problem with performance using query with unnest after migrating from V9.1 to V9.2 and higher
Date
Msg-id 15768.1474554930@sss.pgh.pa.us
Whole thread Raw
In response to Re: Problem with performance using query with unnest after migrating from V9.1 to V9.2 and higher  (Igor Neyman <ineyman@perceptron.com>)
List 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 by date:

Previous
From: Igor Neyman
Date:
Subject: Re: Multiple-Table-Spanning Joins with ORs in WHERE Clause
Next
From: Igor Neyman
Date:
Subject: Re: Multiple-Table-Spanning Joins with ORs in WHERE Clause