From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | tender wang <tndrwang(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Why cann't simplify stable function in planning phase? |
Date: | 2023-02-08 10:24:33 |
Message-ID: | bab9da93cb7949ec13647728c510801fde40ab5a.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2023-02-08 at 16:59 +0800, tender wang wrote:
> In evaluate_function(), I find codes as shown below:
>
> /*
> * Ordinarily we are only allowed to simplify immutable functions. But for
> * purposes of estimation, we consider it okay to simplify functions that
> * are merely stable; the risk that the result might change from planning
> * time to execution time is worth taking in preference to not being able
> * to estimate the value at all.
> */
> if (funcform->provolatile == PROVOLATILE_IMMUTABLE)
> /* okay */ ;
> else if (context->estimate && funcform->provolatile == PROVOLATILE_STABLE)
> /* okay */ ;
> else
> return NULL;
>
> The codes say that stable function can not be simplified here(e.g. planning phase).
> I want to know the reason why stable function can not be simplified in planning phase.
> Maybe show me a example that it will be incorrect for a query if simplify stable function in
> planning phases.
Query planning and query execution can happen at different times and using
different snapshots, so the result of a stable function can change in the
meantime. Think of prepared statements using a generic plan.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2023-02-08 10:27:20 | Re: Why cann't simplify stable function in planning phase? |
Previous Message | Tomas Vondra | 2023-02-08 10:16:47 | Re: pglz compression performance, take two |