From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Subplan result caching |
Date: | 2018-05-23 17:56:41 |
Message-ID: | 20180523175641.576fev5rwwd5usp6@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-05-23 12:51:38 -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> > On 23/05/18 19:25, Tom Lane wrote:
> >> To make this
> >> patch safe, I think you'd need to grovel through the subquery and make
> >> sure that the parameters are only used as inputs to operators that belong
> >> to the type's default btree or hash opfamily. (Many other cases would
> >> work in practice, but we have no semantic knowledge that would let us be
> >> sure of that.)
>
> > Hmm. First thing that comes to mind is to use the raw bytes as cache
> > key, only treating Datums as equal if their binary representation is
> > identical.
>
> Ah. That would work, though it'd make the number of subquery executions
> even less predictable (since some logically-equal values would compare
> as physically unequal).
As long as there's no volatile functions, would anybody care?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2018-05-23 18:00:18 | Re: [PATCH] Clear up perlcritic 'missing return' warning |
Previous Message | Alvaro Herrera | 2018-05-23 17:45:18 | Re: [PATCH] Clear up perlcritic 'missing return' warning |