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

From: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
To: Mike Mascari <mascarm(at)mascari(dot)com>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW
Date: 2002-11-13 08:02:38
Message-ID: 20021113080238.GA7413@wallace.ece.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tommi Maekitalo 2002-11-13 08:28:38 Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW
Previous Message Mike Mascari 2002-11-13 07:40:40 Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW