91–100 of 238 posts
Copying from https://stackoverflow.com/questions/12115397/is-it-against-l... : The standard license ( http://www.oracle.com/technetwork/licenses/standard-license-... ) you agree to when you download software from the Oracle Technology Network (OTN) does state that you're not allowed to disclose benchmarks. You may not: > - disclose results of any program benchmark tests without our prior consent. I sadly suspect that…
For those still on Oracle, why? Is it regulations or executives demanding certified solutions? And if so then with so many bugs at what point does certification become a negative signal?
- planner hints
- better statistics (including ways to manually create statistics)
- no vacuum
- automatic planner adjustment when true cost was off
- better planning for prepared statements
- active-active clustering with RAC
- vendor support for running on SAN including snapshots
- usable query analysis tools provided by the vendor (pg_stat_statements alone doesn't cut it)
- datapump much faster than pg_dump
- better connection management
- out of the box backup tooling
edit: I haven't used Oracle in 4 years, all of that was available to me back then.
Earlier quoted context omitted.
> Rollback of DDLs Oracle can't roll back these (create table/drop index etc)? That really surprises me. Pretty certain MSSQL can, because I've used it. Amazed, actually, that oracle can't.
Very few databases support transactional DDL, meaning that you can do something like: BEGIN; DROP TABLE foo; CREATE TABLE bar (t int); ROLLBACK; ...and it will just work as you expect. Oracle doesn't, nor does MSSQL. As far as I know, other than Postgres, only Sybase ASE, Informix, DB2 UDB, and Firebird support transaction DDL.
Earlier quoted context omitted.
> Rollback of DDLs Oracle can't roll back these (create table/drop index etc)? That really surprises me. Pretty certain MSSQL can, because I've used it. Amazed, actually, that oracle can't.
MSSQL can roll back DDL. But the DDL changes are not fully transactional, as other trans sacri one can see new columns and tables before the DDL transacrion commits. Postgres gets it right. DDL is contained in the transacrion until commit.
That's not a very useful comparison. Databases are made to execute queries, not to install them. The only useful metric is performance and features (and price, of course). Sure, Oracle is bloated and pain to manage, but if it works faster, provides unique features and costs less in the end, people will use it.
Right but by that metric Oracle is archaic. Just look at Postgres[0] supported column data types and then look at Oracle[1]. Better data types means more tightly defined columns, which means fewer bugs/less defensive programming/reduced maintenance/reduced code complexity. No doubt someone will be along shortly to tell me "you don't NEED it!" and then tell me how to hack constraints into making it act like something…
Copying from https://stackoverflow.com/questions/12115397/is-it-against-l... : The standard license ( http://www.oracle.com/technetwork/licenses/standard-license-... ) you agree to when you download software from the Oracle Technology Network (OTN) does state that you're not allowed to disclose benchmarks. You may not: > - disclose results of any program benchmark tests without our prior consent. I sadly suspect that…
People are scared of corporations, but they don't really have much ability to damage you. They can't cause physical harm to your body. They can't take away your loved ones. All they can do is take some money. You started life with $0, so you can probably make it all back. It would be inconvenient, but not an existential crisis. The likeliest outcome is that nothing will happen. The second most likely outcome is that…
Don't generalise from your life; you only have to take care of yourself and Ayaya. A majority of people are deeply committed to a relationship/family/tribe, where losing all one's money definitely constitutes a crisis.
That's not a very useful comparison. Databases are made to execute queries, not to install them. The only useful metric is performance and features (and price, of course). Sure, Oracle is bloated and pain to manage, but if it works faster, provides unique features and costs less in the end, people will use it.
But being able to freely/quicly stand up database servers and quickly create/drop databases makes development and testing much simpler and more reliable.
Given the question: "How do you know that deploying this thing will work?"
- When it's quick/legal to stand up fresh servers and create databases, the answer can be "I tested it, just now, and it works." - Otherwise you end up in "I read through it and it looks good" or perhaps "We tried most of it on the test instance last week before the other team started using it."
I much prefer the former.
Earlier quoted context omitted.
Query hints are one reason. I'm not a fan of Oracle as a company, but for certain usage patterns you need query hints and Postgres doesn't support them.
PostgreSQL provides a variety of options for tuning both the query planner's strategy and the per-table statistical analyses that are used as input to the query planner itself. These tuning methods are actually far more robust than the query hints that are commonly used in other databases, including Oracle.
Usually it's some three-way join with n:n:n relations which breaks Postgres' neck. I know exactly where the query should start from, statistics can't possibly know because they have no knowledge about the data distribution in adjacent tables.
I use CTE to "fix" this but the query would be faster without it.
Another issue is that plans can just fall over and you have absolutely no tools available to see what the old plan was, unless you ran explain before and saved the plan. You also have no way to force the old plan while you analyze the issue. This has caused more production outages than I'm willing to admit. With Oracle it would take me one minute to see what the issue is, and I could make the database use the old plan without changing a single line of code.
Anyone here use Patroni for automated high availability with postgres? Does it “just work” or do you need a lot of housekeeping?
We recently rolled out Patroni on k8s and it definitely does not “just work”. I suppose once you get it up and running, there’s some truth to that, but it’s one of the most hostile pieces of software I’ve come across. This isn’t a complaint, after all, Zalando don’t owe me anything. But the documentation, the project structure, the contributors...it all reveals very clearly that this is really just some internal tool…
The Spilo docker container which packages PostgreSQL + Patroni was also always publicly available from the first day. I agree, the Spilo is a bit opinionated due to the way how it is used at Zalando.
These two projects have quite a long history and originally weren't even targeted to be deployed on K8s because back in 2015 K8s wasn't absolutely suited for running stateful workloads.
The most opinionated one is Zalando Postgres-Operator, and yes, first it was the internal tooling and was solving our specific problems. Now I would also argue that with such an amount of external contributors it already became a way more general solution.
After all, Patroni is so general, that we call it a template for PostgreSQL HA. You can take it and build something that you need/want without relying on Spilo and Zalando Postgres-Operator. Speaking of Patroni@K8s, there are already two very nice examples: Crunchy Data PostgreSQL Operator and StackGres are both relying on Patroni for running PostgreSQL HA on K8s.
What I am interested in, is what are those features / problems. And if Postgre has a roadmap for those improvement.
I mean not just Oracle. Outside of HN the majority of dev and cooperation still swears by MySQL. I often wished HN instead of constantly hyping a technology, tell me up front what are the Cons. And hopefully everyone will make up their own mind whether the Pros and the Cons are worth trying it out.