>
> >> That will (IMO) not solve the problem, since different threads will be
> >> setting and resetting the store format. My suggestion would be to use a
> >> pool of connections and each thread work off one connection, and
> returning
> >> it to the po
setting.
>>
>> -Original Message-
>> From: Rahul Raj [mailto:rahul@option3consulting.com]
>> Sent: Wednesday, December 13, 2017 10:23 PM
>> To: user@drill.apache.org
>> Subject: Re: Drill session and jdbc connections
>>
>> We are using a one connectio
esetting.
>
> -Original Message-
> From: Rahul Raj [mailto:rahul@option3consulting.com]
> Sent: Wednesday, December 13, 2017 10:23 PM
> To: user@drill.apache.org
> Subject: Re: Drill session and jdbc connections
>
> We are using a one connection and multiple statemen
Raj [mailto:rahul@option3consulting.com]
Sent: Wednesday, December 13, 2017 10:23 PM
To: user@drill.apache.org
Subject: Re: Drill session and jdbc connections
We are using a one connection and multiple statements for creating the CSV
files. I will surround the calls with a finally to reset
l, run the RESET command
> to ensure the default state is set.
>
> https://drill.apache.org/docs/reset/
>
>
>
> -Original Message-
> From: Rahul Raj [mailto:rahul@option3consulting.com]
> Sent: Wednesday, December 13, 2017 2:17 AM
> To: user@drill.apache.org
> Su
the RESET command to
ensure the default state is set.
https://drill.apache.org/docs/reset/
-Original Message-
From: Rahul Raj [mailto:rahul@option3consulting.com]
Sent: Wednesday, December 13, 2017 2:17 AM
To: user@drill.apache.org
Subject: Drill session and jdbc connections
Hi
Hi,
How is a drill session related to a drill jdbc connection instance? What
happens in a pool of connections when one connection changes the
store.format? I am seeing some mix-ups where a parquet row is written as an
array of multiple records(rather than multiple columns) when another thread