Re: Overriding the optimizer

From: Jaime Casanova <systemguards(at)gmail(dot)com>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Overriding the optimizer
Date: 2005-12-17 12:31:40
Message-ID: c2d9e70e0512170431m1275018cq363851364cdbb54b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 ;)

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Bruce Momjian 2005-12-17 14:56:49 Re: Simple Join
Previous Message Simon Riggs 2005-12-17 09:15:53 Re: Should Oracle outperform PostgreSQL on a complex