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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Igor Neyman <ineyman(at)perceptron(dot)com>
Cc: "Knels, Udo" <U(dot)Knels(at)treubuch-it(dot)de>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Problem with performance using query with unnest after migrating from V9.1 to V9.2 and higher
Date: 2016-09-22 14:35:30
Message-ID: 15768.1474554930@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Igor Neyman <ineyman(at)perceptron(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Igor Neyman 2016-09-22 14:36:24 Re: Multiple-Table-Spanning Joins with ORs in WHERE Clause
Previous Message Igor Neyman 2016-09-22 14:32:53 Re: Multiple-Table-Spanning Joins with ORs in WHERE Clause