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.l.johnson@xxxxxxx     |
| 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                                  |
+---------------------------------------------------------+


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org