Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW

Поиск
Список
Период
Сортировка
От Ross J. Reedstrom
Тема Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW
Дата
Msg-id 20021113080238.GA7413@wallace.ece.rice.edu
обсуждение исходный текст
Ответ на Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW  (Mike Mascari <mascarm@mascari.com>)
Ответы Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Nov 13, 2002 at 02:40:40AM -0500, Mike Mascari wrote:
> Ross J. Reedstrom wrote:
> >
> >For this query, the difference is 160 ms vs. 2 sec. Any reason for this
> >change?
> 
> I could be way off base, but here's a shot in the dark:
> 
>
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3D0885E1.8F369ACA%40mascari.com&rnum=3&prev=/groups%3Fq%3DMike%2BMascari%2Bsecurity%2BTom%2BLane%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den
> 
> At the time I thought PostgreSQL was doing something naughty by 
> allowing user functions to be invoked on data that would 
> ultimately not be returned. Now I know how Oracle uses VIEWS for 
> row security: Oracle functions invoked in DML statements can't 
> record any changes to the database. So if the above is the 
> cause, I wouldn't have any problems with the patch being 
> reversed. Maybe separate privileges for read-only vs. read-write 
> functions are in order at some point in the future though...

Bingo, that solved it. I'm back to 160 ms. What does Tom feel about
removing this? Is there some way the planner could have known which
was the smarter/faster order of application?

Ross


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mike Mascari
Дата:
Сообщение: Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW
Следующее
От: Tommi Maekitalo
Дата:
Сообщение: Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW