David Rowley <dgrowleyml@xxxxxxxxx> writes: > On Tue, 27 Aug 2024 at 13:40, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> Yeah, it looks like that condition on "table_name" is not getting >> pushed down to the scan level anymore. I'm not sure why not, >> but will look closer tomorrow. > So looks like it was the "Make Vars be outer-join-aware." commit that > changed this. Yeah, I got that same result by bisecting. It seems like it's somehow related to the cast to information_schema.sql_identifier: we are able to get rid of that normally but seem to fail to do so in this query. There was a smaller increase in the runtime at dfb75e478 "Add primary keys and unique constraints to system catalogs", but that seems to just be due to there being more rows in the relevant catalogs. (That's from testing the query in an empty database; probably the effect of dfb75e478 would be swamped in a production DB anyway.) regards, tom lane
