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:
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
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 |