Re: Strange query planner behavior

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> so 30. 11. 2019 v 11:29 odesílatel EffiSYS / Martin Querleu <
> martin(dot)querleu(at)effisys(dot)fr> napsal:
>> I think the main question is whether the query planner is able to pre
>> calculate subqueries with = to use the value returned to get the good query
>> plan

> SELECT * FROM LIVRAISON WHERE ID_MASTER = (SELECT 10)
> this query is optimized as two independent queries - SELECT * FROM
> LIVRAISON WHERE ID_MASTER and SELECT 10. Although "SELECT 10" has const
> result, first query desn't calculate it. Postgres planner doesn't expect so
> somebody will write these queries, and don't try to detect const table
> results.

More to the point: usually, when somebody writes something that way,
it's because they *want* to hide the sub-select expression from the
upper-level query. It's pretty common to use this syntax to prevent an
expensive or volatile function from being recalculated multiple times,
for instance. It would certainly not be that hard to pull up the
expression out of a trivial scalar sub-select, but we'll reject any
patch to do that, because it would make many more users unhappy than
happy. If you don't want this behavior, don't write it that way.

As Pavel suggests, "IN" is a reasonable alternative if you don't
want to skip the "(SELECT ...)" wrapper for some reason.

regards, tom lane