From: | Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Strange behavior of function date_trunc |
Date: | 2021-05-05 14:48:42 |
Message-ID: | 76928e6e-348e-dd3a-d623-99e5fcef1292@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 05.05.2021 17:11, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
>> On 5/5/21 3:23 PM, Pavel Luzanov wrote:
>>> It is very likely that the date_trunc function in the following
>>> example is executed for each line of the query. Although it marked
>>> as a STABLE and could only be called once.
>> It could, but that's just an option - the database may do that, but
>> it's not required to do it. In this case it might be beneficial, but
>> it'd make the planner more complex etc.
> Yeah, there simply is not any provision for caching the results of
> stable functions in the way Pavel seems to be imagining. People have
> played around with patches for that, but nothing's been accepted.
Thank you for the clarification. It's not very obvious, at least for me.
--
Pavel Luzanov
Postgres Professional: https://postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Ashwin Kini | 2021-05-05 18:42:20 | Trusty postgresql-client-9.5_9.5.17-1.pgdg14.04+1_amd64.deb removed ? |
Previous Message | Pavel Luzanov | 2021-05-05 14:19:43 | Re: Strange behavior of function date_trunc |