Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Drill >> mail # dev >> Sql Option Statements


Copy link to this message
-
Re: Sql Option Statements
Why do we even need transactions when we perform no updates?

Tim
On Sun, Jan 12, 2014 at 1:03 PM, Jason Altekruse
<[EMAIL PROTECTED]>wrote:

> Hi Aman,
>
> Thanks for the feedback. I will be defining both global and session local
> options in my implementation. We will be assuming that session local
> settings will be tied to the node a client connection is associated with, a
> loss of the connection will lose the session and all settings. Global
> settings will be added to distributed cache to persist and apply throughout
> all instances of Drill in the cluster.
>
> Another level of granularity that seems to be supported is transaction
> local settings, at least for SQL server all settings within a transaction
> are reset to their defaults hen the transaction has finished. I do not know
> the standard well, but I would assume that transactions are included. In a
> widely distributed system like Drill, I'm uncertain how we are going to be
> able to manage locks necessary to keep transactions consistent. Still for
> full compliance I assume we will need to visit the issue eventually, and
> might just look at the right place to store those settings when we have a
> concept of transactions in Drill.
>
> - Jason
>
>
> On Fri, Jan 10, 2014 at 5:28 PM, Aman Sinha <[EMAIL PROTECTED]> wrote:
>
> > Hi Jason,
> > so I suppose there are 3 types of option settings that you might be
> > considering:
> >     1. Something like 'SET <option_name> TO <value> '   which would be
> done
> > before running a query and would be valid for all subsequent queries run
> in
> > that session.
> >     2. A configuration file (e.g drill.conf) that would contain the
>  <key,
> > value> pairs of options and their values and these would be parsed and
> > applicable for *ALL* sessions
> >     3. I suppose another requirement is to support EXPLAIN commands with
> > either 'physical' or 'logical' options.
> >
> > I would vote for limiting the types of options supported in Drill.  In
> > general, the database vendors have various proprietary set of options.  I
> > would think SQL server is too flexible in terms of supporting the
> > options... maybe we could look at Postgres (or MySQL) instead which has a
> > more standard single token option name and (for the most part)  single
> > token values too.
> >
> > As another point of reference, Oracle supports optimizer 'hints' where
> you
> > can specify enabling or disabling specific options  (example, enable hash
> > join, merge join etc.) for a particular subquery within a query.. but I
> > don't think at this stage we should worry about that.
> >
> > Aman
> >
> >
> > On Fri, Jan 10, 2014 at 2:28 PM, Jason Altekruse
> > <[EMAIL PROTECTED]>wrote:
> >
> > > Hello Drill Team,
> > >
> > > I have been working the past few days on implementing the SQL options
> > > statements within the optiq parser and Drill and unfortunately have
> hit a
> > > few major decision points.
> > >
> > > I was hoping to make the changes to optiq as minimal as possible, and
> > > design a simple parsing rule that would work for all future Drill
> > options.
> > > Right now I have it implemented with a single identifier as an option
> > name,
> > > and an identifier or literal as the value (using various types for
> > options
> > > needing int, decimal or datetime literals). I did need to add an
> > additional
> > > rule to parse the reserved word ON, as it is used to set most of the
> > > options I have found and is not parsed as a valid identifier.
> > >
> > > I have looked at a number of the options available in various SQL
> > > implementations, but have found no reference to any ANSI standard
> > options.
> > > I am assuming that they are all vendor specific, but any documentation
> > on a
> > > set of standard options would be greatly appreciated. For anyone who
> > knows
> > > their way around the full standard, I found an old draft available here
> > (I
> > > did not realize that the current one was behind a paywall). I did not
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB