Re: BUG #7598: Loss of view performance after dump/restore of the view definition
| От | Vaclav Juza |
|---|---|
| Тема | Re: BUG #7598: Loss of view performance after dump/restore of the view definition |
| Дата | |
| Msg-id | 507D0BA9.7010705@xitee.com обсуждение исходный текст |
| Ответ на | Re: BUG #7598: Loss of view performance after dump/restore of the view definition (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: BUG #7598: Loss of view performance after dump/restore
of the view definition
|
| Список | pgsql-bugs |
I was doing the test on the released 9.2.1 (without the patch). The times of the query with the original view were floating around those values, so it's maybe just a luck that it was slightly slower on 9.2.1. The big difference was after the view was restored with the explicit cast. The purpose of this updated test case was mainly that you can check which change between 9.1.4 and 9.2.1 could have caused this performance regression and if this change can have some negative impact (on different queries) even after applying the patch. Thanks for the patch anyway. Regards, Vaclav Juza On 15/10/2012 17:44, Tom Lane wrote: > Vaclav Juza <vaclav.juza@xitee.com> writes: >> I have modified the test case (it is more similar to the real-word >> query), so that now it is slower on 9.2.1 than on 9.1.4 (the version >> with the explicit cast): > > FWIW, testing this on HEAD (with the patch I committed last week), > I get a plan that's about 10% faster than 9.1; or if I disable > index-only scans for a more level playing field, it's just about > equivalent to 9.1. > > regards, tom lane >
В списке pgsql-bugs по дате отправления: