From: "Knels, Udo" <U.Knels@treubuch-it.de>
To: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Problem with performance using query with unnest after
 migrating from V9.1 to V9.2 and higher
Thread-Topic: [PERFORM] Problem with performance using query with unnest after
 migrating from V9.1 to V9.2 and higher
Thread-Index: AdH5O1H79waUwOJ+T8+JxfQvcAsxrQbBdU2AACL1roA=
Date: Mon, 26 Sep 2016 15:59:58 +0000
Message-ID: <d47753011ac64182aa3fada94c6a4710@EXCH-1.ddd-do.de>
References: <1d6ce510f1cf4dfcad73b15ff8ff98a4@EXCH-1.ddd-do.de>
 <283046e4-a37f-d8cb-85dc-52d1286e8ffb@BlueTreble.com>
In-Reply-To: <283046e4-a37f-d8cb-85dc-52d1286e8ffb@BlueTreble.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Hi,

Thank you very much for your answers.

Yes, 50 rows aren't enough, but the original table has about 14 million row=
s and after analyzing the table I got the same result.=20

We changed our functions and used string_to_array instead of unnest and its=
 ok.=20

It was not only a problem with one value to be selected. The problem exists=
 with three or more too. Maybe the implementation of unnest has changed fro=
m V9.1 to V9.5. In V9.1 there was only one array as argument. Since V9.4 we=
 can use more than one array as argument. And so the planner works differen=
t. So, if we change from one version to another in the future, we have to c=
heck the PostgreSQL-functions if the behaviour of the function or the plann=
er has changed and then replace the function. It would be great if we could=
 see this in the documentation.

Greetings

Udo Knels
treubuch IT GmbH


--=20
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance