Feature request: set planner flags on views

Started by Ryan Mackover 22 years ago2 messages
#1Ryan Mack
rmack@mackman.net

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.

#2Bruno Wolff III
bruno@wolff.to
In reply to: Ryan Mack (#1)
Re: 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.