Fix issues with bigint sum -> numeric conversion

[ruchirK]

Functional changes here in the first commit:

• make sum_int64 have the same behavior as the rest of the reduce path
• make our reduce elision logic output the correct type

and then theres a small debug output change to pgwire in the second commit.

I tested this manually against Chris's query and it works but I'm not sure if thats suitable for an integration test or if we should do something else. Afaik we're not able to specify primary keys from sql primitives. @benesch do you have any thoughts?

---

This change is 

[benesch]

Code looks good, but you think we could wrap up the bug into a test case somehow?

[ruchirK]

Code looks good, but you think we could wrap up the bug into a test case somehow?

Yeah I'm not sure:

We could definitely repeat the query on the mz_scheduling_elapsed log. I'm ok with doing that in a testdrive test + a comment indicating why. Doing this does seem very brittle though.

Other than that:

• I don't know how to declare primary keys on sources, views or tables. Oh wait I actually just thought of something as I was typing -- views with reductions have primary keys. so i think attempting to double compute the sum of a view will hit this elision bug. I can do that.

• I don't know how to force sum_int64 to execute

[benesch]

In SLT you can just create a table with a primary key actually!

[ruchirK]

tests added!

[benesch]

Awesome! Looks great to me.

[cirego]

Thanks for looking at this!

[ruchirK]

I'm afk for a few hours but feel free to merge when green if you want

…

On Wed, Jan 13, 2021, 5:49 PM Nikhil Benesch ***@***.***> wrote: ***@***.**** approved this pull request. Awesome! Looks great to me. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5299 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6UHJH7JH7KYHA7SU4ZWV3SZYPP5ANCNFSM4WAIEVDA> .