If this is specific to the CLoudera-provided xDBC dirvers, probably
the CLoudera forums are the best place to proceed:
community.cloudera.com/t5/Interactive-Short-cycle-SQL/bd-p/Impala
On Sat, Jun 16, 2018 at 4:17 AM, Fawze Abujaber wrote:
> Hi Mostafa,
>
> Can these pre statements avoided?
>
>
Hi Mostafa,
Can these pre statements avoided?
Any configuration or any set statement that can pypass these statements?
On Fri, 15 Jun 2018 at 18:48 Mostafa Mokhtar wrote:
> @Lars Volker
> Many JDBC/ODBC drivers issue show tables & describe statements ahead of
> executing a query by default.
@Lars Volker
Many JDBC/ODBC drivers issue show tables & describe statements ahead of
executing a query by default.
On Fri, Jun 15, 2018 at 8:45 AM Lars Volker wrote:
> As far as I know the driver should not generate additional statements. Can
> you share what software you're using to connect
As far as I know the driver should not generate additional statements. Can
you share what software you're using to connect to Impala through the
driver? I suspect that that software generated these queries, possibly to
do some schema discovery.
Cheers, Lars
On Thu, Jun 14, 2018 at 10:14 PM Jim
I don’t think I understand the statement. Under what conditions are
additional DDL statements generated by the driver? What exact query did you
enter and what was generated instead?
On Thu, Jun 14, 2018 at 5:44 PM Sunil Parmar wrote:
> The Impala JDBC driver generates additional DDL statements.
The Impala JDBC driver generates additional DDL statements.
select column1,column2 from table limit 0
or
show tables
or
use dwh;
or
describe table
If DDL are expensive; is there a way to avoid this ?
Sunil Parmar
On Mon, May 21, 2018 at 5:48 PM Tim Armstrong
wrote:
> SET is very cheap
SET is very cheap because it just changes a value in the user's session.
There's no interaction with any other services.
DDL operations can be a lot more expensive, although they don't compete
with executing queries for resources. For the most part those DDL
operations you mentioned consume
Thanks Tim,
If i got your point right, then SET operation is affecting the client Java
memory and not considered as part of the impala daemon memory limit, right?
Is this correct also for invalidate meta data and Refresh or alter table
... recover partitions? Are all of these client operations?
