From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: Rick Vincent <rvincent@temenos.com>, pgsql-performance@postgresql.org,
        Manoj Kumar <manojkumar@temenos.com>,
        Herve Aubert <haubert@temenos.com>
Subject: Re: Postgres not using index on views
In-reply-to: <20200407045929.GJ2228@telsasoft.com>
References: 
 <DM6PR04MB492354C0895FB26EDFBE1D82C1C20@DM6PR04MB4923.namprd04.prod.outlook.com>
 <20200407045929.GJ2228@telsasoft.com>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Mon, 06 Apr 2020 23:59:29 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <26255.1586236149.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 07 Apr 2020 01:09:09 -0400
Message-ID: <26256.1586236149@sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.com> writes:
> On Mon, Apr 06, 2020 at 02:19:59PM +0000, Rick Vincent wrote:
>> The following query takes an extremely long time for only 180 rows, and=
 what this means is that we would have to index anything appearing in the =
where clause for every table in order to use views because the views seem =
not to consider the select clause.  Why is that and does anyone know a way=
 around this?

> Is there a reason why you don't store the extracted value in its own col=
umn ?

The planner seems to be quite well aware that the slower query is going to
be slower, since the estimated costs are much higher.  Since it's not
choosing to optimize into a faster form, I wonder whether it's constrained
by semantic requirements.  In particular, I'm suspicious that some of
those functions you have in the view are marked "volatile", preventing
them from being optimized away.

Beyond that guess, though, there's really not enough info here to say.
The info we usually ask for to debug slow-query problems is explained
at

https://wiki.postgresql.org/wiki/Slow_Query_Questions

			regards, tom lane