From: | Tomasz Rybak <bogomips(at)post(dot)pl> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Overriding the optimizer |
Date: | 2005-12-16 14:47:19 |
Message-ID: | 1134744439.5124.7.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Dnia 16-12-2005, pią o godzinie 16:16 +1300, Mark Kirkwood napisał(a):
> Craig A. James wrote:
>
> >
> > What would be cool would be some way the developer could alter the plan,
> > but they way of doing so would strongly encourage the developer to send
> > the information to this mailing list. Postgres would essentially say,
> > "Ok, you can do that, but we want to know why!"
> >
>
> 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.....
I think you could use SPI for that.
There is function SPI_prepare, which prepares plan,
and SPI_execute_plan, executing it.
These functions are defined in src/backend/executor/spi.c.
I think (someone please correct me if I'm wrong) you could
prepare plan yourself, instead of taking it from SPI_prepare,
and give it to SPI_execute_plan.
SPI_prepare calls _SPI_prepare_plan, which parses query and calls
pg_analyze_and_rewrite. In your version don't call this function,
but provide PostgreSQL with your own plan (not-optimised according to
PostrgeSQL, but meeting your criteria).
--
Tomasz Rybak <bogomips(at)post(dot)pl>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-16 15:23:21 | Re: ALTER TABLE SET TABLESPACE and pg_toast |
Previous Message | Jaime Casanova | 2005-12-16 14:45:34 | Re: Overriding the optimizer |