Michael Rys
My feedback
-
13 votes
Michael Rys supported this idea ·
-
4 votes
Michael Rys supported this idea ·
-
4 votes
An error occurred while saving the comment -
3 votes
Michael Rys supported this idea ·
-
3 votes
An error occurred while saving the comment -
9 votes
Michael Rys supported this idea ·
-
4 votes
Michael Rys supported this idea ·
-
4 votes
An error occurred while saving the comment Michael Rys commented
Do you mean catalog views a la usql.tables? Or some visual tool experience?
-
4 votes
An error occurred while saving the comment Michael Rys commented
Parquet support with snappy is now in public preview. See https://github.com/Azure/AzureDataLake/blob/master/docs/Release_Notes/2018/2018_Spring/USQL_Release_Notes_2018_Spring.md#built-in-parquet-extractor-and-outputter-is-in-public-preview
ORC support is in private preview.
Are there other places you need SNAPPY support?
-
5 votes
Michael Rys supported this idea ·
-
6 votes
Michael Rys supported this idea ·
-
7 votes
Michael Rys supported this idea ·
-
8 votes
An error occurred while saving the comment Michael Rys commented
Why can't you just move the constant comparison into the WHERE clause?
-
10 votes
Michael Rys supported this idea ·
An error occurred while saving the comment Michael Rys commented
Thanks for filing this request. since we currently do not want to go through the cost of enforcing PK/FK constraints (which could be very costly given tera byte sized tables) we would need to introduce some special syntax to support this. We are adding this now to our backlog.
-
12 votes
Michael Rys supported this idea ·
-
11 votes
Michael Rys supported this idea ·
-
19 votes
An error occurred while saving the comment Michael Rys commented
One of the problems in scale-out systems is to provide a scalable IDENTITY function to avoid the need to synchronize or serialize. One way to work around it is with ROW_NUMBER(), another is to use GUIDs instead of an integer value, since GUID creation does not need a global coordination.
-
43 votes
Michael Rys supported this idea ·
-
41 votes
Michael Rys supported this idea ·
An error occurred while saving the comment Michael Rys commented
Thanks for your request. Indeed row-level updates and deletes are useful and it is on our longterm roadmap. Given the current processing architecture, the current work-arounds are:
1. Use partitioned tables to partition the data so that you can either drop partitions or at least minimize the reprocessing costs.
2. Reprocess the data by creating a new version with the dropped data deleted. -
15 votes
Michael Rys supported this idea ·
Thanks for your request Geoff. Right now we are focusing on finalizing the C# notebook experience and if we see enough requests, we will take a closer look at enabling F# as well. If you have a specific production scenario in mind, feel free to reach out to me via my twitter @MikeDoesBigData.