On Fri, Apr 22, 2016 at 10:11 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> The most basic thing I can think of to rationalise my thinking for this is:
>
> # create table v (v varchar);
> # create view v_v as select lower(v) v from v;
> # explain verbose select upper(v) from v_v;
> QUERY PLAN
> -------------------------------------------------------------
> Seq Scan on public.v (cost=0.00..30.40 rows=1360 width=32)
> Output: upper(lower((v.v)::text))
> (2 rows)
>
> It seems that you're proposing that the aggregate equivalence of this should be;
>
> QUERY PLAN
> -------------------------------------------------------------
> Seq Scan on public.v (cost=0.00..30.40 rows=1360 width=32)
> Output: upper((v)::text)
> (2 rows)
>
> which to me seems wrong, as it's hiding the fact that lower() was called.
>
> My arguments don't seem to be holding much weight, so I'll back down,
> although it would still be interesting to hear what others have to say
> about this.
Yeah, I'd be happy to have more people chime in. I think your example
is interesting, but it doesn't persuade me, because the rule has
always been that EXPLAIN shows the output *columns*, not the output
*rows*. The disappearance of some rows doesn't change the list of
output columns. For scans and joins this rule is easy to apply; for
aggregates, where many rows become one, less so. Some of the existing
choices there are certainly arguable, like the fact that FILTER is
shown anywhere at all, which seems like an artifact to me. But I
think that now is not the time to rethink those decisions.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company