Re: Not using index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniele Orlandi <daniele(at)orlandi(dot)com>
Cc: psql-hackers <hackers(at)postgreSQL(dot)org>
Subject: Re: Not using index
Date: 2000-05-10 06:18:23
Message-ID: 17068.957939503@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniele Orlandi <daniele(at)orlandi(dot)com> writes:
> [ example snipped ]
> It seems like the index is used only if * appears in the target list.

There is certainly not a dependence on * as such. However, the
estimated row width does affect the cost estimate for operations like
SORT, where we have to guess how many rows will fit in memory. It looks
to me like your example case is right near the boundary where the system
thinks that index scan and sort are of roughly equal cost, so relatively
small changes will push the choice in one direction or the other.
This should not be taken as an indication that someone actually
considered the specific examples and decided it should act that way!
It just falls out of the behavior of the cost-estimate-driven planner
structure. Ideally, the hope is not that this sort of choice is
perfectly right all the time; my ambition only extends to the hope that
if the system thinks index scan and sort are of roughly equal cost,
then indeed they are, and so it wouldn't matter a whole lot which one
gets picked.

Of course we aren't all that close to meeting the ideal goal :-(.
I'm assuming that you are complaining because one or the other of
these plans is actually much cheaper than the other in your example.
You have, however, carefully refrained from giving us any hint which.
Care to fess up with more details?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2000-05-10 07:38:54 Comparison PostgreSQL 7.0 vs. Interbase2000
Previous Message Thomas Lockhart 2000-05-10 05:44:02 Re: misc questions