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

From: Mike Mascari <mascarm(at)mascari(dot)com>
To: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW
Date: 2002-11-13 07:40:40
Message-ID: 3DD201F8.4020406@mascari.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ross J. Reedstrom wrote:
> Hey Hackers -
> I was testing beta5 and found a performance regression involving
> application of constraints into a VIEW - I've got a view that is fairly
> expensive, involving a subselet and an aggregate. When the query is
> rewritten in 7.2.3, the toplevel constraint is used to filter before
> the subselect - in 7.3b5, it comes after.
>
> 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...

Mike Mascari
mascarm(at)mascari(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ross J. Reedstrom 2002-11-13 08:02:38 Re: performance regression, 7.2.3 -> 7.3b5 w/ VIEW
Previous Message Ross J. Reedstrom 2002-11-13 06:22:11 performance regression, 7.2.3 -> 7.3b5 w/ VIEW