Re: Invalid optimization of VOLATILE function in WHERE clause?

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Florian Schoppmann" <Florian(dot)Schoppmann(at)emc(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Invalid optimization of VOLATILE function in WHERE clause?
Date: 2012-09-19 19:39:12
Message-ID: 5059D910020000250004A51A@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> It still seems like awfully weird behavior.
>
> Why? The WHERE condition relates only to the output of the _stats
> subquery, so why shouldn't it be evaluated there, rather than
> after the join?

In another thread, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> It's easier to understand why this is if you realize that SQL has
> a very clear model of a "pipeline" of query execution.
> Conceptually, what happens is:
>
> 1. Form the cartesian product of the tables listed in FROM (ie,
> all combinations of rows).
>
> 2. Apply the WHERE condition to each row from 1, and drop rows
> that don't pass it.

People expect that the results will be consistent with this model,
even if the implementation is optimized "under the covers". I think
correct semantics should trump performance here.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ktm@rice.edu 2012-09-19 19:47:35 Re: Invalid optimization of VOLATILE function in WHERE clause?
Previous Message Robert Haas 2012-09-19 18:58:42 Re: Invalid optimization of VOLATILE function in WHERE clause?