Re: [HACKERS] Making clausesel.c Smarter
От | David Steele |
---|---|
Тема | Re: [HACKERS] Making clausesel.c Smarter |
Дата | |
Msg-id | f8c5a235-5f82-912f-7781-1d0a9979a160@pgmasters.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Making clausesel.c Smarter (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Making clausesel.c Smarter
|
Список | pgsql-hackers |
On 2/26/17 1:41 AM, Robert Haas wrote: > On Fri, Feb 24, 2017 at 3:30 PM, David Rowley > <david.rowley@2ndquadrant.com> wrote: >> It would be good to improve the situation here in the back branches >> too, but I'm thinking that the attached might be a little invasive for >> that? > > My experience has been that customers - at least EnterpriseDB > customers - do not appreciate plan changes when they upgrade to a new > minor release. Most people have production installations that are > basically working; if not, they wouldn't be in production. Even if > they're getting a good plan only by some happy accident, they're still > getting it, and a change can cause a good plan to flop over into a bad > plan, which can easily turn into a service outage. The people who had > a bad plan and get flipped to a good plan will be happy once they > realize what has changed, of course, but that's not really enough to > make up from the panicked calls from customers whose stuff falls over > when they try to apply the critical security update. > > I think the basic think you are trying to accomplish is sensible, > though. I haven't reviewed the patch. This patch applies cleanly and compiles at cccbdde. I agree with Robert that back patching would likely not be a good idea. Anyone familiar with the planner available to review this patch? It also seems like this would be a (relatively) simple patch to start with for anyone that is interested in learning more about the planner. -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: