From: Tom Lane <tgl@sss.pgh.pa.us>
To: Markus Demleitner <msdemlei@ari.uni-heidelberg.de>
cc: pgsql-general@lists.postgresql.org
Subject: Re: Index not used in certain nested views but not in others
In-reply-to: <20250430151647.7kootztymzznydn5@victor>
References: <20250430151647.7kootztymzznydn5@victor>
Comments: In-reply-to Markus Demleitner <msdemlei@ari.uni-heidelberg.de>
	message dated "Wed, 30 Apr 2025 17:16:47 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1400977.1746046929.1@sss.pgh.pa.us>
Date: Wed, 30 Apr 2025 17:02:09 -0400
Message-ID: <1400978.1746046929@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1400978.1746046929%40sss.pgh.pa.us>
Precedence: bulk

Markus Demleitner <msdemlei@ari.uni-heidelberg.de> writes:
> So, when the SELECT statement on dfbsspec.ssa stands along in the view
> definition, Postgres does the right thing; when the exact same query
> stands in a UNION ALL with other tables, Postgres doesn't use the
> index.  Hu?

It's hard to be sure when you've shown us no table definitions and
only fragments of the view definitions.  But I suspect what is
happening here is that the view's UNIONs are causing a data type
coercion of raw_spectra.pub_did before it gets to the top level
of the view output.  That might interfere with the planner's ability
to see that the outer query's join operator is compatible with
the table's index.

			regards, tom lane