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

On Sat, 2002-05-25 at 03:52, Andrew McMillan wrote:
> On Sat, 2002-05-25 at 02:25, Ron Johnson wrote:
> >
> > 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?
>
> There is no work around for this one. In some circumstances the indexes
> in a PostgreSQL database will contain 'dirty' information, and so to get
> the correct answer in these cases PostgreSQL has to go to the real
> table.

"Dirty information"? Is this a consequence of READ COMMITTED
transactions?

> For my personal view I'm OK with the current behaviour. It has
> tradeoffs, and this is one of the negatives, but although I find myself
> doing this interactively quite often I only very rarely find myself
> doing it inside an application.

IMO, when a "proprietary" DBA (like me) hears that that statement
does table scans, s/he will be stunned, and wonder what other
"gotchas" are lurking out there awaiting someone who wants to
query enterprise-sized tables. The main reason that I am
researching Postgres (a _real_ database) is to see whether we
can move historical data off the proprietary system, and on to
something less expensive that people can run ad-hoc queries
against...

--
+---------------------------------------------------------+
| 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 |
+---------------------------------------------------------+