Tom Lane wrote:
>
> mlw <markw@mohawksoft.com> writes:
> > That is the difference, in another post Tom said he could not get
> > excited about 10.9 second execution time over a 7.96 execution
> > time. Damn!!! I would. That is wrong.
>
> Sure. Show us how to make the planner's estimates 2x more accurate
> (on average) than they are now, and I'll get excited too.
>
> But forcing indexscan to be chosen over seqscan does not count as
> making it more accurate. (If you think it does, then you don't
> need to be in this thread at all; set enable_seqscan = 0 and
> stop bugging us ;-))
Oh, come on Tom, surely I have been around long enough to lend credence that
wish to have a positive affect on PostgreSQL development.
enable_seqscan=0, disallows sequential scan, that is not what I am saying. This
is a problem I (and others) have been yapping about for a long time.
(Please remember, I USE PostgreSQL, I have a vested interest in it being the
best RDBMS available.)
I just think there is sufficient evidence to suggest that if a DBA creates an
index, there is strong evidence (better than statistics) that the index need be
used. In the event that an index exists, there is a strong indication that,
without overwhelming evidence, that the index should be used. You have admitted
that statistics suck, but the existence of an index must weight (heavily) on
the evaluation on whether or not to use an index.
