MIME-Version: 1.0
References: <CA+7GS+Ff3PWbeJNbi7e6Nqfgh4HOTzyNoyGsBwFeivkUKDUwBA@mail.gmail.com>
In-Reply-To: <CA+7GS+Ff3PWbeJNbi7e6Nqfgh4HOTzyNoyGsBwFeivkUKDUwBA@mail.gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Sat, 31 Aug 2024 01:27:44 +1200
Message-ID: <CAApHDvpvaf7M=Fz0vHW3TQMX3oco7L11O5Sa3TO3uUF8pHvQnw@mail.gmail.com>
Subject: Re: optimizing a join against a windowed function
To: James Brown <james@instrumentl.com>
Cc: pgsql-general@lists.postgresql.org, Gabriel Sinkin <gabe@instrumentl.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAApHDvpvaf7M%3DFz0vHW3TQMX3oco7L11O5Sa3TO3uUF8pHvQnw%40mail.gmail.com>
Precedence: bulk

On Fri, 30 Aug 2024 at 23:36, James Brown <james@instrumentl.com> wrote:
> I have two tables: one named taxpayers which has a goodish number of colu=
mns an an integer PK id, and one named insights, which has a taxpayer_id fo=
reign key to taxpayers, a year, and (again) a lot of other columns. There's=
 an index on insights (taxpayer_id, year DESC). I'm executing the following=
 SQL:

> If there's only a single value in the IN clause, the EXPLAIN plan looks g=
reat:

> However, if there are multiple rows in the IN clause, the optimizer decid=
es to execute the subselect against the entire giant table, and it is not g=
reat:

Unfortunately, you've hit a limitation with the EquivalenceClass code.
With the "ON latest_insights.taxpayer_id =3D taxpayers.id WHERE
taxpayers.id =3D 650974", the planner is able to deduce that
latest_insights.taxpayer_id is also equal to 650974 and push that
condition down into the common table expression. With the "ON
latest_insights.taxpayer_id =3D taxpayers.id WHERE taxpayers.id IN (?,
?)" query, the EquivalenceClass code doesn't handle this, so the
optimisation isn't performed. We likely should improve this someday,
but for today, think of it as an unimplemented optimisation rather
than a bug.

> If I add in a second repetitive WHERE clause, it goes back to being happy=
, but that feels a bit like a hack:

That's likely your best bet on how to make the planner do what you
want, provided you're able to given the query is inside a view.

David