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
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 |