Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-novice by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group