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

On Fri, 2002-05-24 at 08:54, Tom Lane wrote:
> Ron Johnson <ron.l.johnson@cox.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.l.johnson@cox.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                                  |
+---------------------------------------------------------+