| From: | Elvis Pranskevichus <elprans(at)gmail(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #16368: Incorrect function inlining in the presence of a window function |
| Date: | 2020-04-16 01:17:30 |
| Message-ID: | 7058335.0AJ8ntve86@hammer.magicstack.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wednesday, April 15, 2020 5:14:05 P.M. PDT Tom Lane wrote:
> In point of fact, there are many ways in which CASE and related
> constructs fail to guarantee evaluation order, as noted in
> https://www.postgresql.org/docs/current/sql-expressions.html#SYNTAX-EX
> PRESS-EVAL
>
> The particular case mentioned there seems to be about the same as
> here: constant-folding happens even in CASE arms that will never be
> reached at runtime.
Yes, but function arguments aren't constants are they? At least the
documentation makes no effort to mention that.
> would be quite unhappy with the performance impact of de-optimizing
> CASE that way.
I'm not arguing for the general de-optimization for CASE, just for not
treating arguments of inlined functions as constants in the CASE
statement. For arguments of a prepared statement this optimization
makes even less sense.
Elvis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Elvis Pranskevichus | 2020-04-16 02:06:39 | Re: BUG #16368: Incorrect function inlining in the presence of a window function |
| Previous Message | David Rowley | 2020-04-16 00:40:24 | Re: BUG #16369: Segmentation Faults and Data Corruption with Generated Columns |