The query planner does an abysmal job with some of the most important
views in my DB.  The execuation time with seq_scan disabled is 25ms versus
110ms when seq_scan is enabled.  Instead of modifying all my code to
temporarily disable seq_scan around all places this query is made (or
making a procedure for it), I think it would be useful to allow views to
have their own set of planner flags.

CREATE VIEW foo AS SELECT foo FROM bar SET enable_seq_scan TO OFF AND SET ...;

I'll leave the exact syntax to y'all, but you get the idea.  Anybody else 
think this would be useful?

Thanks, Ryan Mack
Please cc me on all replies.

Thu, 26 Jun 2003 07:32:02 -0700 (PDT)
Ryan Mack <rmack@mackman.net>
Feature request: set planner flags on views
On Thu, Jun 26, 2003 at 07:32:02 -0700,
  Ryan Mack <rmack@mackman.net> wrote:
> The query planner does an abysmal job with some of the most important
> views in my DB.  The execuation time with seq_scan disabled is 25ms versus
> 110ms when seq_scan is enabled.  Instead of modifying all my code to
> temporarily disable seq_scan around all places this query is made (or
> making a procedure for it), I think it would be useful to allow views to
> have their own set of planner flags.
> 
> CREATE VIEW foo AS SELECT foo FROM bar SET enable_seq_scan TO OFF AND SET ...;
> 
> I'll leave the exact syntax to y'all, but you get the idea.  Anybody else 
> think this would be useful?

In most cases it is better to try to figure out why the wrong plan is
being used and see if there is some configuration change which will
work better for queries in general. Forcing a plan can be a problem down
the road when the database hase changed enough that original forced
plan is no longer a good one.
Even if you were to force a particular plan, it really wouldn't make
much sense to force it with a view, since depending on how the view
was used different plans might be better.

Fri, 27 Jun 2003 22:25:21 -0500
Bruno Wolff III <bruno@wolff.to>
Re: Feature request: set planner flags on views