From: Tom Lane <tgl@sss.pgh.pa.us>
To: Wells Oliver <wells.oliver@gmail.com>
cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: Joining to views & the query planner
In-reply-to: 
 <CAOC+FBX1rXLZi9o+TjJWGfYWzZmAg6s2GUTUtqhDKA6cQtzaYA@mail.gmail.com>
References: 
 <CAOC+FBX1rXLZi9o+TjJWGfYWzZmAg6s2GUTUtqhDKA6cQtzaYA@mail.gmail.com>
Comments: In-reply-to Wells Oliver <wells.oliver@gmail.com>
	message dated "Wed, 15 Jun 2022 11:39:26 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <534504.1655319874.1@sss.pgh.pa.us>
Date: Wed, 15 Jun 2022 15:04:34 -0400
Message-ID: <534505.1655319874@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/534505.1655319874%40sss.pgh.pa.us>
Precedence: bulk

Wells Oliver <wells.oliver@gmail.com> writes:
> Hi: we do this kind of thing a lot, where we CREATE VIEW v AS SELECT
> a.col1, b.col2 FROM a JOIN b ON a.b_id = b.id -- and then we write
> downstream queries to do something like SELECT * FROM v WHERE col2 = 123.
> Assuming here both a.col1 and a.col2 are indexed using BTREE.

> It seems from my experience that this bogs down, that the query planner
> doesn't necessarily know how to use indexes well from the joined table (b),
> and it ends up scanning a lot more rows than we might think necessary.

A simple test of that pattern gave me a reasonable-looking plan,
so I suspect you are leaving out critical details.  How about
a concrete example?

(pgsql-performance would likely be a better venue, btw.)

			regards, tom lane