Re: Optimizer picks an ineffient plan - Mailing list pgsql-general

From Stephan Szabo
Subject Re: Optimizer picks an ineffient plan
Date
Msg-id 20030906122309.C20687-100000@megazone.bigpanda.com
Whole thread Raw
In response to Re: Optimizer picks an ineffient plan  ("Relaxin" <noname@spam.com>)
List pgsql-general
On Fri, 5 Sep 2003, Relaxin wrote:

> And your argument about how it will increase other queries is pointless to
> me. Will you still stand by this argument when the PG folks find a situation
> where the optimizer creates a terrible plan and the only way to fix is to
> add additional logic, based on what you are saying, it's not worth it
> because it could add .001 seconds of additional processing.

I've tried to say that you need to balance the cost of the optimization
against its potential gain in the cases it helps, the frequency of those
cases, the ability to solve the problems other ways and against the
development time that is used in it.  There isn't a push button with two
states, best and not best.

When you want to argue about an optimization you should think about:
 a) What does the optimization actually mean (actual specification, not
vague words)
 b) What cases is the optimization legal for (doesn't change results,
doesn't violate spec, etc)
 c) What cases does the optimization help (as separate from b in that some
cases may not actually be faster but the optimization is legal)
 d) What is the gain over the cases that the optimization helps
 e) What is the penalty over the cases that the optimization does not help

If someone feels strongly about it or feels that they have the time,
they can (and should be generally promoted to) attempt the optimization.
If the optimization is not expensive or has better than expected gains or
good side effects, it's likely to get accepted.


pgsql-general by date:

Previous
From: Greg Stark
Date:
Subject: Re: Needed function IF(expr, expr, expr)
Next
From: elein
Date:
Subject: Re: Trunc in Postgres