| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
| Cc: | Oleg Ivanov <o15611(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19340: Wrong result from CORR() function |
| Date: | 2025-12-03 00:17:32 |
| Message-ID: | 531516.1764721052@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
I tried the attached realization of your idea, and it does seem
very marginally faster than what I did; but it's like a 1.8%
slowdown instead of 2%. Might be different on a different
machine of course. But I think we should choose on the basis
of which semantics we like better, rather than such a tiny
performance difference.
I'm coming around to the conclusion that your way is better,
though. It seems good that "any NaN in the input results in
NaN output", which your way does and mine doesn't.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| wip-detect-constant-input-exactly-2.patch | text/x-diff | 4.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-12-03 01:27:56 | Re: BUG #19340: Wrong result from CORR() function |
| Previous Message | Dean Rasheed | 2025-12-02 23:48:28 | Re: BUG #19340: Wrong result from CORR() function |