Hey, let me know if there's any way I can help.
I would argue that making even a small improvement here would be beneficial
to many.
On Tue, Jul 21, 2020 at 11:59 AM Dmitry Dolgov <9erthali...@gmail.com>
wrote:
> > On Thu, Oct 3, 2019 at 3:33 AM Pavel Trukhanov <
> pa
Thanks for your input.
As for real-world applications – being a founder of a server monitoring
saas (okmeter) I have access to stats on hundreds of postgres installations.
It shows that IN with a variable number of params is ~7 times more used
than ANY(array).
On Wed, Jun 26, 2019 at 11:10 PM T
ams, not
consts, because I think this is the most common case actually.
And existing tests only check consts in "IN" list.
I don't see a way to implement such a test with the existing test
infrastructure.
Though if that might be considered out of the scope for this TODO, it
would be okay with me.
I would appreciate any feedback.
---
Pavel Trukhanov
Thanks for your reply
> If I understand correctly, "IN (...)" is reprecented by A_Expr with kind
> AEXPR_IN, and only in transformAExprIn converted to ArrayExpr if possible.
That seems to be correct, yes, thank you.
> So probably it doesn't makes sense to introduce another one.
Though I might've
Thanks for the feedback.
I thought once again about separating IN from ARRAY, with refactoring
etc as Tom suggested, and now I don't think it's worth it to do so.
I've tried to implement that, and besides that it will require to
change things in every part of query processing pipeline, it seems
th
