Kevin Brown <kevin@sysexperts.com> writes:
> Hmm...any chance, then, of giving aggregate functions a means of
> asking which table(s) and column(s) the original query referred to so
> that it could do proper optimization on its own?
You can't usefully do that without altering the aggregate paradigm.
It won't help for min() to intuit the answer quickly if the query
plan is going to insist on feeding every row to it anyway.
> For instance, for a
> "SELECT min(x) FROM mytable" query, the min() function would be told
> upon asking that it's operating on column x of mytable, whereas it
> would be told "undefined" for the column if the query were "SELECT
> min(x+y) FROM mytable". In the former case, it would be able to do a
> "SELECT x FROM mytable ORDER BY x LIMIT 1" on its own,
Don't forget that it would also need to be aware of whether there were
any WHERE clauses, joins, GROUP BY, perhaps other things I'm not
thinking of.
In the end, the only reasonable way to handle this kind of thing is
to teach the query planner about it. Considering the small number
of cases that are usefully optimizable (basically only MIN and MAX
on a single table without any WHERE or GROUP clauses), and the ready
availability of a SQL-level workaround, it strikes me as a very
low-priority TODO item.
regards, tom lane