Why do we even need transactions when we perform no updates?
On Sun, Jan 12, 2014 at 1:03 PM, Jason Altekruse
> 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
> > before running a query and would be valid for all subsequent queries run
> > that session.
> > 2. A configuration file (e.g drill.conf) that would contain the
> > 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
> > 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