Re: Why sequential scan when there's a supporting index? - Mailing list pgsql-novice

From Andrew McMillan
Subject Re: Why sequential scan when there's a supporting index?
Date
Msg-id 1022316741.11106.547.camel@kant.mcmillan.net.nz
Whole thread Raw
In response to Re: Why sequential scan when there's a supporting index?  (Ron Johnson <ron.l.johnson@cox.net>)
Responses Re: Why sequential scan when there's a supporting index?  (Ron Johnson <ron.l.johnson@cox.net>)
List pgsql-novice
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.

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.

Regards,
                    Andrew.
--
--------------------------------------------------------------------
Andrew @ Catalyst .Net.NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/        PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201    MOB: +64(21)635-694    OFFICE: +64(4)499-2267
       Are you enrolled at http://schoolreunions.co.nz/ yet?


pgsql-novice by date:

Previous
From: Tom Lane
Date:
Subject: Re: Nondestructive cluster, equivalent SQL?
Next
From: Ron Johnson
Date:
Subject: Re: Why sequential scan when there's a supporting index?