Re: performance regression in 9.2/9.3
От | Merlin Moncure |
---|---|
Тема | Re: performance regression in 9.2/9.3 |
Дата | |
Msg-id | CAHyXU0yV9zGEZWr+w0UPCDs6dVfSQx=pwuXgQEEnZdxUVW5Wkg@mail.gmail.com обсуждение исходный текст |
Ответ на | performance regression in 9.2/9.3 (Linos <info@linos.es>) |
Ответы |
Re: performance regression in 9.2/9.3
Re: performance regression in 9.2/9.3 |
Список | pgsql-hackers |
On Thu, Jun 5, 2014 at 6:32 AM, Linos <info@linos.es> wrote: > Hello all, > > This is a continuation of the thread found here: > http://www.postgresql.org/message-id/538F2578.9080001@linos.es > > Considering this seems to be a problem with the planner I thought that maybe would be a better idea to post this problemhere. > > To summarize the original thread I upgraded a medium (17Gb) database from PostgreSQL 8.4 to 9.3 and many of the queriesmy application uses started performing a lot slower, Merlin advised me to try disabling nestloop, this helped outfor the particular query I was asking about but it is not a solution that I "can/would like" to use in the general case. > > I simplified a little bit the original query and I have added another one with same problem. I believe the basic problem (this is just one example; I've anecdotally seen this myself) is that changes in the query planner (which I don't follow and fully understand) in recent versions seem to be such that the planner makes better decisions in the presence of good information but in certain cases makes worse choices when dealing with bad information. Statistics errors tend to accumulate and magnify in complicated plans, especially when the SQL is not optimally written. I have no clue what the right solution is. There's been several discussions about 'plan risk' and trying to get the server to pick plans with better worse case behavior in cases where statistics are demonstrably suspicious. Maybe that would work but ISTM is a huge research item that won't get solved quickly or even necessarily pan out in the end. Nevertheless, user supplied test cases demonstrating performance regressions (bonus if it can be scripted out of generate_series) are going to be key drivers in finding a solution. merlin
В списке pgsql-hackers по дате отправления: