From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Artacus <artacus(at)comcast(dot)net>, PostgreSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Problem with volatile function |
Date: | 2008-06-19 06:43:04 |
Message-ID: | 4859FFF8.3030908@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> writes:
>> Personally I'd expect that to only evaluate once. It's saying "where
>> f_name.counter in this row is equal to some single random value
>> generated at the start of the query". The parameters of the random()
>> function do not depend on the input, so Pg evaluates it once rather than
>> with each row.
>
> No, that's not the model that we use. In my view, the semantics
> specified by the SQL standard are that
> SELECT ... FROM a, b, c WHERE ...
> are that you notionally form the Cartesian product of a X b X c
> and then evaluate the WHERE condition at each row of the product
> to find out which rows make it into the SELECT result. Obviously,
> the DBMS is going to try like heck to optimize the execution of that
> model, but its optimizations should not change the results.
Thanks for explaining that; I'd completely misunderstood the way Pg
handles evaluation of expressions that don't explicitly reference fields
in the records being scanned.
I think the workarounds I suggested should still work, despite the
incorrect reasoning on which they were based.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2008-06-19 07:01:28 | Re: PITR base backup -- stop server or not? |
Previous Message | Artacus | 2008-06-19 06:19:27 | Re: Problem with volatile function |