Re: Overriding the optimizer - Mailing list pgsql-performance

From Jaime Casanova
Subject Re: Overriding the optimizer
Date
Msg-id c2d9e70e0512170431m1275018cq363851364cdbb54b@mail.gmail.com
Whole thread Raw
In response to Re: Overriding the optimizer  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: Overriding the optimizer
List pgsql-performance
> > Yeah it would - an implementation I have seen that I like is where the
> > developer can supply the *entire* execution plan with a query. This is
> > complex enough to make casual use unlikely :-), but provides the ability
> > to try out other plans, and also fix that vital query that must run
> > today.....
>
> Being able to specify an exact plan would also provide for query plan
> stability; something that is critically important in certain
> applications. If you have to meet a specific response time requirement
> for a query, you can't afford to have the optimizer suddenly decide that
> some other plan might be faster when in fact it's much slower.

Plan stability doesn't mean time response stability...
The plan that today is almost instantaneous tomorrow can take hours...

--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator ;)

pgsql-performance by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Should Oracle outperform PostgreSQL on a complex
Next
From: Bruce Momjian
Date:
Subject: Re: Simple Join