Re: generalizing the planner knobs - Mailing list pgsql-hackers

From Csaba Nagy
Subject Re: generalizing the planner knobs
Date
Msg-id 1133803864.4779.179.camel@coppola.muc.ecircle.de
Whole thread Raw
In response to Re: generalizing the planner knobs  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
[snip]
> I want to be sure my existing queries keep using the plans they've been using
> until I allow them to change.
> 
> I don't want to sit down and type "select count(*) from users" and have it not
> work correctly (ie, use a sequential scan) because the system is so single
> mindedly tuned for the OLTP application.
> 

Now this is exactly what I've had in mind... it would be nice to
"fixate" a plan for some of the queries, and let the planner choose the
best for all the rest. I think some other data bases have something like
an "optimizer plan stability" feature, providing "outlines" of query
plan bundles. This is maybe too much, but specifying that for a certain
query I definitely want to use one index and not the other would be
nice...

On another note, it might be interesting to have some kind of "prepare
analyze", where the planner is allowed to go and get some more detailed
estimation from the actual table data based on the hard-coded parameter
values, and produce some more detailed statistics for the parameterized
values so it can then produce hot-shot plans for the actual parameter
values on each execution... I wonder if this makes any sense. This way
we could have some very detailed statistics directly supporting the
queries we actually use. I would call this kind of prepare for the most
used/problematic queries from time to time, and the planner should
decide what statistics it needs to support it and go and get it...

Cheers,
Csaba.





pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: generalizing the planner knobs
Next
From: Zoltan Boszormenyi
Date:
Subject: Re: SERIAL type feature request