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

From Greg Stark
Subject Re: generalizing the planner knobs
Date
Msg-id 87slt7bh8u.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: generalizing the planner knobs  (Hans-Juergen Schoenig <postgres@cybertec.at>)
Responses Re: generalizing the planner knobs
List pgsql-hackers
Hans-Juergen Schoenig <postgres@cybertec.at> writes:

> I think I know what Greg is trying to say: I think in this plan stability
> does not mean that the plan has to be completely fixed - usually it is all
> about indexing.

"Usually" problems occur because someone hasn't run analyze at all. That's not
what I'm talking about. I'm talking about a large mature system where the DBA
has everything tuned and adjusted properly and just wants to get a good
night's sleep, confident that the nightly analyze isn't going to suddenly
change the performance of existing queries.

> Adding hints to some comments or to the statement itself is not a  good
> solution as well. This is why I proposed a table or some flag  telling the
> planner what to favour (= always use a certain index). So  the basic idea is
> not to turn index of in general but to have the  chance to do it on a per index
> basis. I guess this would not be to  complex to implement and it solves 90% of
> all problems without having  to hide some information inside comments (which is
> no good at all).

I disagree that this is a reasonable solution.

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.


-- 
greg



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] snprintf() argument reordering not working
Next
From: Csaba Nagy
Date:
Subject: Re: generalizing the planner knobs