Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW - Mailing list pgsql-hackers

From Ross J. Reedstrom
Subject Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW
Date
Msg-id 20021113080238.GA7413@wallace.ece.rice.edu
Whole thread Raw
In response to Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW  (Mike Mascari <mascarm@mascari.com>)
Responses Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Mike Mascari
Date:
Subject: Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW
Next
From: Tommi Maekitalo
Date:
Subject: Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW