drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Venki Korukanti (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DRILL-4729) Add support for prepared statement implementation on server side
Date Fri, 17 Jun 2016 17:53:05 GMT
Venki Korukanti created DRILL-4729:
--------------------------------------

             Summary: Add support for prepared statement implementation on server side
                 Key: DRILL-4729
                 URL: https://issues.apache.org/jira/browse/DRILL-4729
             Project: Apache Drill
          Issue Type: Sub-task
          Components: Metadata
            Reporter: Venki Korukanti
            Assignee: Venki Korukanti
             Fix For: 1.8.0


Currently Drill JDBC/ODBC driver implements its own prepared statement implementation, which
basically issues limit 0 query to get the metadata and then executes the actual query. So
the query is planned twice (for metadata fetch and actual execution). Proposal is to move
that logic to server where we can make optimizations without disrupting/updating the JDBC/ODBC
drivers.

*  {{PreparedStatement createPreparedStatement(String query)}}. {{PreparedStatement}} object
contains the following:
** {{ResultSetMetadata getResultSetMetadata()}}
*** {{ResultsSetMetadata}} contains methods to fetch info about output columns of the query.
What info these methods provide is given in this [spreadsheet|https://docs.google.com/spreadsheets/d/1A6nqUQo5xJaZDQlDTittpVrK7t4Kylycs3P32Yn_O5k/edit?usp=sharing].
It lists the ODBC/JDBC requirements and what Drill will provided through object {{ResultsSetMetadata}}.
*** Server can put more info here which is opaque to client and use it in server when the
client sends execute prepared statement query request. 

Overload the current submit query API to take the {{PreparedStatement}} returned above. 

In the initial implementation, server side implementation of {{createPreparedStatement}} API
is implemented as follows:
* Runs the query with {{LIMIT 0}}, gets the schema
* Convert the query into a binary blob and set it as opaque object in {{PreparedStatement}}.

When the {{PreparedStatement}} is submitted for execution, reconstruct the query from binary
blob in opaque component of {{PreparedStatement}} and execute it from scratch. 

Opaque component of the {{PreparedStatement}} is where we can save more information which
we can use for optimizations/speedups.

NOTE: We are not going to worry about parameters in prepared query in initial implementation.
We can provide the functionality later if there is sufficient demand from Drill community.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message