Re: again on index usage

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Daniel Kalchev" <daniel(at)digsys(dot)bg>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: again on index usage
Date: 2002-01-11 11:46:42
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA42128AD@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> This topic seems to come up a lot. Is there something we are missing in
> the FAQ?

Most of the reports we seem to see are the usual, "but the seq scan is actually
faster" case. Daniel actually has a case where the optimizer chooses a bad plan.

The difficulty seems to be, that the optimizer cooses a correct plan for an idle
system, but with his workload the index path would be far better (2 vs 4 Minutes).

This is one of the main problems of the current optimizer which imho rather
aggressively chooses seq scans over index scans. During high load this does
not pay off. My preference would actually be a way to make the optimizer
choose a plan that causes minimal workload, and not shortest runtime
(which will obviously only be fast with low overall workload)
The reasoning behind this is, that during low workload your response times
will be good enough with a "bad" plan, but during high workload your response
times will be best with a plan that produces the least additional workload.

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff 2002-01-11 14:20:28 Re: Bad interval external representation
Previous Message Holger Krug 2002-01-11 10:59:34 Re: Problems with simple_heap_update and Form_pg_relcheck