Re:Amazons move off Oracle caused Prime Day outage in one of...
by kodablah on Wednesday October 24, 2018 @08:55PM
(#18297778)
A gross, slanted article about an internal systems issue. The correlation here is like saying my car accident was due to me taking a different route to work. All here that have done production refactorings and migrations know what's up. Good thing this article got a CS professor to explain, got some Oracle CEO quotes in there, failed to inform why Amazon might want to choose Postgres over Oracle, etc. Feels a bit like a shill article, but at least mgmt will have something appear in their search results when their own tech teams suggest a similar transition.
Re:Amazons move off Oracle caused Prime Day outage in one of...
by orf on Wednesday October 24, 2018 @08:31PM
(#18297679)
Not completely related to the article, but more about debugging on Oracle v Postgres.
On Oracle to get a query plan you need to prefix the query with some statements that insert the query plan into another table (EXPLAIN PLAN FOR iirc), and you need to supply a unique ID for the query.
Ok, cool. So to get it out you need to SELECT some random poorly named extension function, giving the table and the unique ID you created above. It's not clear there is any easy way of knowing if that function is available or the user has permissions to read from that table.
Alright. So pretty bad, but not impossible. But then you run smack dab into an obscure Oracle error with a very unhelpful message. You slowly begin to realize that you cannot get the query plan for any query that uses parameters. At all.fE
In Postges it's simply a EXPLAIN ANALYZE VERBOSE prefix.
This is what Oracle wants, this is what Oracle gets.
On Oracle to get a query plan you need to prefix the query with some statements that insert the query plan into another table (EXPLAIN PLAN FOR iirc), and you need to supply a unique ID for the query.
Ok, cool. So to get it out you need to SELECT some random poorly named extension function, giving the table and the unique ID you created above. It's not clear there is any easy way of knowing if that function is available or the user has permissions to read from that table.
Alright. So pretty bad, but not impossible. But then you run smack dab into an obscure Oracle error with a very unhelpful message. You slowly begin to realize that you cannot get the query plan for any query that uses parameters. At all.fE
In Postges it's simply a EXPLAIN ANALYZE VERBOSE prefix.