Re: Why sequential scan when there's a supporting index?

On Fri, 2002-05-24 at 08:54, Tom Lane wrote:
> Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> writes:
[snip]
> Improving the handling of max() has been on the TODO list for awhile,
> but most of the hacker community considers it low priority because of
> the availability of the above workaround. Also, Postgres has a very
> generalized black-box approach to aggregate functions, so no one's been
> able to think of a reasonably clean way to teach the planner that some
> aggregates are connected to index sort ordering.

How do I vote on increasing the priority of "fixing max()"?

SELECT MAX(FOO) FROM BAR;
SELECT tx_date, COUNT(*) FROM t_lane_tx GROUP BY tx_date;

These are awfully common statements on proprietary RDBMSs,
and it confuses the _heck_ out of someone migrating to
Postgres.

Btw, "SELECT tx_date, COUNT(*) FROM t_lane_tx GROUP BY tx_date;"
also does a Seq Scan on t_lane_tx. What's the best work-around
for this query?

--
+---------------------------------------------------------+
| Ron Johnson, Jr. Home: ron(dot)l(dot)johnson(at)cox(dot)net |
| Jefferson, LA USA http://ronandheather.dhs.org:81 |
| |
| "I have created a government of whirled peas..." |
| Maharishi Mahesh Yogi, 12-May-2002, |
! CNN, Larry King Live |
+---------------------------------------------------------+