Re: Invalid optimization of VOLATILE function in WHERE clause?

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Florian Schoppmann <Florian(dot)Schoppmann(at)emc(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Invalid optimization of VOLATILE function in WHERE clause?
Date: 2012-09-20 15:49:01
Message-ID: CAHyXU0xRTBk2w7epr1LEyVmQX41+KhNCScgmZVZZD6CX3rJnyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 20, 2012 at 9:24 AM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>
>> Hm, I bet it's possible (although probably not easy) to deduce
>> volatility from the function body...maybe through the validator.
>> If you could do that (perhaps warning in cases where you can't),
>> then the performance regression-inducing-argument (which I agree
>> with) becomes greatly ameliorated.
>
> For about the last 10 years the Wisconsin Courts have been parsing
> SQL code to generate Java query classes, including "stored
> procedures", and determining information like this. For example, we
> set a readOnly property for the query class by examining the
> statements in the procedure and the readOnly status of each called
> procedure. It wasn't that hard for us, and I'm not sure what would
> make much it harder in PostgreSQL, if we can do it where a parse
> tree for the function is handy.

hm, what do you do about 'after the fact' changes to things the
procedure body is pointing to? what would the server have to do?

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-09-20 15:51:30 Re: XLogInsert scaling, revisited
Previous Message Tom Lane 2012-09-20 15:37:42 Re: XLogInsert scaling, revisited