Re: Query optimization with repeated calculations

Robert McGehee <rmcgehee(at)gmail(dot)com> writes:
> I frequently want to make views that repeat a calculation over and over
> again in lots of columns. In the example below, let’s say it’s (a+b), but
> we can imagine the calculation being much more complicated.

> For example:
> CREATE VIEW AS
> SELECT (a+b)*c as c1, (a+b)*d as d1, (a+b)*e as e1
> FROM table;

> My question is, is PostgreSQL "smart" enough to cache this (a+b)
> calculation in the above example, or does it recalculate it in each column?

Postgres will not notice that there's duplicate subexpressions.

> If it recalculates it in each column, would I generally get better
> performance by using a subquery to convince PostgreSQL to cache the
> result? For example:

> CREATE VIEW AS
> SELECT x*c as c1, x*d as d1, x*e as e1
> FROM (SELECT (a+b) as x, * FROM table) x;

Maybe, if the subexpression is expensive enough (a+b probably doesn't
meet that threshold). You'd need to take care to prevent the
subquery from being "flattened" into the upper query. Typically
this might require an optimization fence like OFFSET 0, which is
problematic for a view because it could prevent optimizations that
are far more important than avoiding duplicated calculations.
CTEs are likewise a rather blunt tool that could cost more than
they save.

It might work better to put the redundant calculations in a LATERAL
subquery, ie

CREATE VIEW AS
SELECT x*c as c1, x*d as d1, x*e as e1
FROM tab, LATERAL (SELECT a+b as x OFFSET 0) ss;

I haven't really experimented, but I think that this'd dodge
most of the optimization pitfalls, except one: in this formulation,
a+b will be evaluated for every "tab" row even if the particular
use of the view does not demand any of the columns that use "x".

regards, tom lane