The problem has a name, and its name is Dean Preston.

Half of the Board of Supervisors at any given time are just as bad as Dean, they’re just less vocal. The actual problem is the SF electorate.

Is it the electorate, or the group of people in power(who can and will corrupt anyone elected)?

Exactly

Voters are getting exactly what the want: talk about affordability, and action to prevent building.

The number one thing that voters anywhere do is to prop up sin eaters like Dean Preston. Then everyone is all like "The problem is DEAN PRESTON" as if one moustache twirling guy with an 8 year term could possibly be responsible for 40 years of policy.

That's being unfair to him, there is tremendous local market for millionaire homeowners that still want to think of themselves as socialist revolutionaries as long as the value of their home never ever drops, and he is merely filling that demand

I wonder when HN gets to the stage that all the negativity is directed towards Austin instead of San Francisco, and when we see all the posts about how tech is ruining Austin.

If you live in Austin, you will already see a lot of anti tech sentiment. That said... the locals dislike everyone who isn't local, and the city attracts people in many different areas and not just Tech.

Austin is huge and there is no shortage of land and no pesky regulations (or at least less of them) that it can continue to support the influx for quite a while now. I don't expect it to be the next SV until we see a few Austin-incubated startups really make it big and hopefully kickstart its own substantial startup ecosystem.

This is an absolutely horrible response by someone who clearly doesn’t live in the area.

PG&E has constantly prioritized shareholder profits over renovating their aging infrastructure. They caused the biggest wildfire in the history of California and are now _finally_ facing a reckoning for their reckless and destructive behavior.

Fix your goddamned infrastructure and get a smaller bonus. That’s what we want.

So the State government has no influence over the choices of PG&E? And here I thought it was a regulated utility. Who knew?

I've seen you mention these inconsistent results twice here in this this thread, but have worked at MemSQL for 5 years and never heard of such an issue. Have you reached out to see if maybe your query / data is not what you expect? I've seen inconsistent results only once, and it was because the default date formats across RDMBSs were different (and was not anticipated).

How would the query/data not be what I expect if If I'm writing the query myself, and looking directly at the sql table definition to create it?

Beyond those considerations, why would the same exact same query (executed several times in rapid succession from the console) produce vastly different results? Also, I should clarify, rewriting the query from "select ... from xyz group by ... having ..." to "select ... from (select * from xyz where ...) group by ..." made the inconsistency goes away, without changing the filtering clause. That does not inspire confidence.

Can you post the full schema and query? Are you sure you are not projecting columns that are not part of the group by expression?

I really appreciate the offer. I got the go-ahead to share this information, where should I direct it?

Here, or https://www.memsql.com/forum/, or memsql-public.slack.com.

To close the loop on this one. We looked at the query and strictly speaking we should be rejecting it b/c HAVING clause is referencing a column that's NOT in group by and NOT an aggregate expression. The query shape is:

  select count(*), a from T group by a having b > 0

In this case b is not allowed to be part of having by ANSI standard.

We let it run b/c some customers migrate from MySQL and MySQL allows this query. You can set MemSQL to be strict about it by setting this variable:

  set session sql_mode = only_full_group_by;

Thanks for taking a look at it. Your position is perfectly reasonable, but given the fact that (at least in my case) the results I got back were subtly wrong, and there's a good chance someone wouldn't notice, it might be a good idea to default this off if it isn't already, with a really stern warning in the config.

I believe you're conflating the name with the actual contents of the post. The demo uses the MemSQL columnstore, which is disk-based and leverages memory only for indexes, metadata, query processing etc.

Point of clarification - MemSQL does not need to be all in-memory, there is also a columnstore that is on-disk and only leverages memory for indexes / column segment information.

Would something like this help you?

https://www.youtube.com/watch?v=8XSf6XfYl64

Developed by a former colleague at http://near.ai/.

This looks interesting, but I would suspect if GitHub implemented wildcard matching, like this:

https://public.gitsense.com/insight/github?r=tensorflow/tens...

they could significantly improve discovery.

Not available yet? Looks interesting. How would it compare to Sourcegraph?

Feel free to reach out to me on our public Slack channel to clear up anything that is fuzzy! I'm an engineer at MemSQL and want to know (1) how I can help and (2) how we can provide non-fuzzy information to the rest of the community.

Channel: chat.memsql.com My UN: eklhad

MemSQL engineer here.

No, we do not offer appliances. We are a software only solution. I do not know of any deployments where RDMA is being utilized today. I'm interested in your use case. If you're so inclined, join chat.memsql.com (my UN is eklhad) and we can converse a bit more rapidly.

Thank you guys for your answers :)

I am charting the landscape of distributed database systems (federated and homogenous). Node interconnectivity is just one of many potential bottlenecks.

With a sufficiently complex query, redistribution of data by hash must occur a number of times for linear scalability (based on my understanding). Ethernet based interconnectivity typically suffers from high CPU utilization and various QoS issues for this particular use case. This also seems to apply to Ethernet based fabric offerings, though I haven't kept up with that field for a couple of years.

If you guys are encountering performance issues connected to either RAM=>CPU loading or data redistribution between nodes, you may want to keep this in mind.

I may get in touch via chat at a later time as I'm slightly more than average interested in HPC database systems :) The more offerings, the better!

Hopefully it isn't. In the event that something goes wrong, we need him here.