+1 (binding)
On 8/25/22 04:03, Mauricio Vargas Sepúlveda wrote:
+1
On 2022-08-24 12:50, Weston Pace wrote:
+1 (non-binding)
On Wed, Aug 24, 2022 at 9:24 AM Keith Kraus
wrote:
+1 (non-binding)
On Wed, Aug 24, 2022 at 12:12 PM David Li wrote:
+1 (binding)
On Wed, Aug 24, 2022, at 12:06,
+1 (non-binding). This is maybe implied but I would add that
modification of extension types must also require a vote and should be
backwards compatible. Furthermore, extension types (particularly
those with extensive parameterization/serialization should discuss how
future additions would be
+1 (non-binding)
On Wed, Aug 24, 2022 at 5:35 PM Micah Kornfield
wrote:
> +1, I assume this doesn't impact python wheels.
>
> On Wed, Aug 24, 2022 at 2:15 PM Sutou Kouhei wrote:
>
> > +1
> >
> > In <7ab9b8ef-d5ca-313f-4b12-79647f32a...@python.org>
> > "[VOTE] C++: switch to C++17" on Wed, 24
+1, I assume this doesn't impact python wheels.
On Wed, Aug 24, 2022 at 2:15 PM Sutou Kouhei wrote:
> +1
>
> In <7ab9b8ef-d5ca-313f-4b12-79647f32a...@python.org>
> "[VOTE] C++: switch to C++17" on Wed, 24 Aug 2022 17:31:52 +0200,
> Antoine Pitrou wrote:
>
> >
> > Hello,
> >
> > I would
+1
In <7ab9b8ef-d5ca-313f-4b12-79647f32a...@python.org>
"[VOTE] C++: switch to C++17" on Wed, 24 Aug 2022 17:31:52 +0200,
Antoine Pitrou wrote:
>
> Hello,
>
> I would like to propose that the Arrow C++ implementation switch to
> C++17 as its baseline supported version (currently C++11).
>
+1
On 2022-08-24 12:50, Weston Pace wrote:
+1 (non-binding)
On Wed, Aug 24, 2022 at 9:24 AM Keith Kraus
wrote:
+1 (non-binding)
On Wed, Aug 24, 2022 at 12:12 PM David Li wrote:
+1 (binding)
On Wed, Aug 24, 2022, at 12:06, Ivan Ogasawara wrote:
+1 (non-binding)
On Wed, Aug 24, 2022 at
I don't know of any work being done to turn Acero into a distributed
query engine.
However, I would hope that Acero can be used in a distributed query
engine, and would be a useful component.
If there are features that Acero would need in this environment (e.g.
some kind of exec node for
I agree with Micah. Moreover, adding "org.apache" does not disambiguate
anything; "arrow" should be the reserved namespace for canonical
(extension) types.
Neal
On Wed, Aug 24, 2022 at 12:31 PM Micah Kornfield
wrote:
> Sorry for beling late. I'm -0.5 on "org.apache.arrow." given people
>
+1 (non-binding)
On Wed, Aug 24, 2022 at 9:24 AM Keith Kraus
wrote:
>
> +1 (non-binding)
>
> On Wed, Aug 24, 2022 at 12:12 PM David Li wrote:
>
> > +1 (binding)
> >
> > On Wed, Aug 24, 2022, at 12:06, Ivan Ogasawara wrote:
> > > +1 (non-binding)
> > >
> > > On Wed, Aug 24, 2022 at 12:00 PM
Sorry for beling late. I'm -0.5 on "org.apache.arrow." given people
previously raising naming concerns about having "apache" and "arrow"
coupled together.I think just "arrow" makes sense here.
I also am not sure about relaxing the 2 language requirement for simple
implementations, but feel
+1 (non-binding)
On Wed, Aug 24, 2022 at 12:12 PM David Li wrote:
> +1 (binding)
>
> On Wed, Aug 24, 2022, at 12:06, Ivan Ogasawara wrote:
> > +1 (non-binding)
> >
> > On Wed, Aug 24, 2022 at 12:00 PM Sasha Krassovsky <
> krassovskysa...@gmail.com>
> > wrote:
> >
> >> ++1 (non-binding)
> >>
>
+1 (binding)
Just to check, these rules will presumably be committed into the documentation
as well?
On Wed, Aug 24, 2022, at 11:24, Antoine Pitrou wrote:
> Hello,
>
> I would like to propose we vote for the following set of rules for
> registering well-known ("canonical") extension types.
>
>
+1 (binding)
On Wed, Aug 24, 2022, at 12:06, Ivan Ogasawara wrote:
> +1 (non-binding)
>
> On Wed, Aug 24, 2022 at 12:00 PM Sasha Krassovsky
> wrote:
>
>> ++1 (non-binding)
>>
>> > 24 авг. 2022 г., в 08:53, Jacob Wujciak
>> написал(а):
>> > + 1 (non-binding)
>> >
>> > Benjamin Kietzman schrieb
+1 (non-binding)
On Wed, Aug 24, 2022 at 12:00 PM Sasha Krassovsky
wrote:
> ++1 (non-binding)
>
> > 24 авг. 2022 г., в 08:53, Jacob Wujciak
> написал(а):
> > + 1 (non-binding)
> >
> > Benjamin Kietzman schrieb am Mi., 24. Aug. 2022,
> > 17:43:
> >
> >> +1 (binding)
> >>
> >> On Wed, Aug 24,
++1 (non-binding)
> 24 авг. 2022 г., в 08:53, Jacob Wujciak
> написал(а):
> + 1 (non-binding)
>
> Benjamin Kietzman schrieb am Mi., 24. Aug. 2022,
> 17:43:
>
>> +1 (binding)
>>
>> On Wed, Aug 24, 2022, 11:32 Antoine Pitrou wrote:
>>
>>> Hello,
>>> I would like to propose that the Arrow
Hi,
Can Java developers please take a look at Larry's proposal below?
As for my 2 cents as a non-Java developer:
That's a detailed and well-explained proposal, thank you.
My only concern is that you're proposing to implement this first as a
set of contiguous vectors. The various
+ 1 (non-binding)
Benjamin Kietzman schrieb am Mi., 24. Aug. 2022,
17:43:
> +1 (binding)
>
> On Wed, Aug 24, 2022, 11:32 Antoine Pitrou wrote:
>
> >
> > Hello,
> >
> > I would like to propose that the Arrow C++ implementation switch to
> > C++17 as its baseline supported version (currently
+1 (binding)
On Wed, Aug 24, 2022, 11:32 Antoine Pitrou wrote:
>
> Hello,
>
> I would like to propose that the Arrow C++ implementation switch to
> C++17 as its baseline supported version (currently C++11).
>
> The rationale and subsequent discussion can be read in the archives here:
>
Hello,
I would like to propose that the Arrow C++ implementation switch to
C++17 as its baseline supported version (currently C++11).
The rationale and subsequent discussion can be read in the archives here:
https://lists.apache.org/thread/9g14n3odhj6kzsgjxr6k6d3q73hg2njr
The exact steps
Hello,
I would like to propose we vote for the following set of rules for
registering well-known ("canonical") extension types.
* Canonical extension types are described and maintained in a separate
document under the format specifications directory:
Le 17/08/2022 à 18:45, Joris Van den Bossche a écrit :
+1 on the overall proposal, documenting those in a central place sounds
good to me.
On Wed, 17 Aug 2022 at 18:10, Antoine Pitrou wrote:
* The specification text to be added *must* follow these requirements
1) It *must* have a
Hi Jayeet,
AFAIU, Acero work mainly focuses on single node multithreaded execution
based on morsel driven parallelism [1].
In your case, there are multiple options IMO. Ex. just use 2 nodes which do
filtering parallely, and then node0 does the join (this reduces
communication). Better yet, if
Hi Arrow Community,
With the release of Acero, we were wondering if Acero can be used in a
distributed environment as for now it looks like Acero is only intended for
a local context. For example, if we have a query plan with a hash join node
at the root and multiple filter project nodes on each
23 matches
Mail list logo
