Executing Parallel Statements to Improve Performance
cockroachlabs.com
Executing Parallel Statements to Improve Performance
1–10 of 15 posts
Re: Executing Parallel Statements to Improve Performance
#2The accompanying RFC, Parallel SQL Statement Execution: https://github.com/cockroachdb/cockroach/blob/0da3da734ce6bf...
Re: Executing Parallel Statements to Improve Performance
#3This seems to be a trend that I see across open source projects. They blog about features that Oracle has had for 25 years as if it's something new. Can someone enlighten me as to why there's interest around X DB's implementation of something that's been built dozens of times before?
Re: Executing Parallel Statements to Improve Performance
#4This seems to be a trend that I see across open source projects. They blog about features that Oracle has had for 25 years as if it's something new. Can someone enlighten me as to why there's interest around X DB's implementation of something that's been built dozens of times before?
With all due respect, Oracle doesn't provide ACID semantics across a cluster spanning several continents...
Re: Executing Parallel Statements to Improve Performance
#5This seems to be a trend that I see across open source projects. They blog about features that Oracle has had for 25 years as if it's something new. Can someone enlighten me as to why there's interest around X DB's implementation of something that's been built dozens of times before?
With all due respect, Oracle doesn't provide ACID semantics across a cluster spanning several continents...
Isn't that exactly what "Extended Distance Oracle RAC Clusters" provide?
Re: Executing Parallel Statements to Improve Performance
#6Earlier quoted context omitted.
With all due respect, Oracle doesn't provide ACID semantics across a cluster spanning several continents...
Isn't that exactly what "Extended Distance Oracle RAC Clusters" provide?
No. That still uses ASM. It's effectively low level IO mirroring and needs fast data-centre interconnects and low-latency.
I work a lot with RAC and it introduces more problems than it solves tbh.
Re: Executing Parallel Statements to Improve Performance
#7Earlier quoted context omitted.
With all due respect, Oracle doesn't provide ACID semantics across a cluster spanning several continents...
Isn't that exactly what "Extended Distance Oracle RAC Clusters" provide?
It's almost a meme. I was often told Companies RAC, experience RAC-caused outages, and then they de-RAC.
Re: Executing Parallel Statements to Improve Performance
#8If you’re inventing new syntax... Wouldn’t an a async/await be more useful - to declaratively indicate the desired dependencies between simultaneously operating statements? That way you can work with the results of an inserted PK or the row count to inform later statements - when needed. Eg. ‘returning async’
Re: Executing Parallel Statements to Improve Performance
#9"CockroachDB maintains strong consistency across a globally-distributed cluster of computers."
No, CockroachDB does not maintain strong consistency across a globally-distributed cluster of computers. It is a "goal", but not the reality.
People reviewed these claims, and they do not hold (see e.g. Aphyr's review)
Re: Executing Parallel Statements to Improve Performance
#10"CockroachDB maintains strong consistency across a globally-distributed cluster of computers." No, CockroachDB does not maintain strong consistency across a globally-distributed cluster of computers. It is a "goal", but not the reality. People reviewed these claims, and they do not hold (see e.g. Aphyr's review)
I think your information is incomplete or out of date. Do you have a source other than the Jepsen blog? That seems to make clear that the two issues that were found in the tested beta release were quickly resolved. [0]