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

From: Andrew McMillan <andrew(at)catalyst(dot)net(dot)nz>
To: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
Cc: PgSQL Novice ML <pgsql-novice(at)postgresql(dot)org>
Subject: Re: Why sequential scan when there's a supporting index?
Date: 2002-05-25 08:52:21
Message-ID: 1022316741.11106.547.camel@kant.mcmillan.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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?

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Ron Johnson 2002-05-25 11:35:30 Re: Why sequential scan when there's a supporting index?
Previous Message Joshua b. Jore 2002-05-24 23:54:39 Re: Nondestructive cluster, equivalent SQL?