Live data from Hacker News

Oracle vs. PostgreSQL – A Comment

postgresql.org

181–190 of 238 posts

Re: Oracle vs. PostgreSQL – A Comment

#181
post #95

Earlier quoted context omitted.

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…

You should store dates with timezone or you can't make calculations like how old is this post. You could base it off system time, but then the calculation have to take into account summer/winter time.

Some times it does not make sense to associate a time component to a date, just because it happens on a day, not at a certain time.

For example, in a lot of countries, Labor Day is on May 1, Christmas on Dec 25. These do not happen at a certain time, and there is no timezone to be associated with these events.

If I'm requesting some user's birthday, I'm going to store it as a date. I don't have a time component. I don't know the time zone. In some cases, dates are just dates ...

Re: Oracle vs. PostgreSQL – A Comment

#182

Earlier quoted context omitted.

> Very few databases support transactional DDL Postgres, SQL Server, Firebird, DB2, SQLite, Ingres, Informix, Teradata, Vertica all support transactional DDL

SQL Server partially supports it - indexes for example are not versioned which causes snapshot transactions to fail if someone rebuilds an index - even if it’s not in scope of the snapshot.

That doesn't sound right by my experience, Could you give a link please? I'm concerned I've not heard of this. Probably because it's MVCC/snapshot isolation which I'm not familiar with.

Re: Oracle vs. PostgreSQL – A Comment

#184
post #178

Earlier quoted context omitted.

people have known this things for quite a while (ie as as far as perf goes oracle is not worth it) and there is a reason why oracle includes that in the license. also, this comparison would not register as a proper “benchmark” as it’s not even close to how you would perform a proper benchmark. it’s more of a data point. on top of that there is the optics of suing a guy that wrote an email over some insane provision i…

> also, this comparison would not register as a proper “benchmark” as it’s not even close to how you would perform a proper benchmark. it’s more of a data point. I would prefer to not have to argue about that in court...

not wanting this is valid.

but at what point do you stand up and not let yourself be bullied? I think a half-decent lawyer can make a proper argument that this is not a benchmark.

Re: Oracle vs. PostgreSQL – A Comment

#185

Earlier quoted context omitted.

Obviously you don't have experience with Oracle or you would have written hundreds of thousands of dollars in license fees... /s

Obviously you don't have experience with Oracle or you would have written millions of dollars in license fees... /s

not sure why a simple joke was worth a downvote -- hope the downvote made you a little bit happier somehow

Re: Oracle vs. PostgreSQL – A Comment

#186

I seriously doubt that the author has 20 years of Oracle DBA experience yet not know why Oracle takes up more disk space that Postgres. There are so many features in Oracle for which there is no equivalent in Postgres. -Sharding -Java Pool -Oracle Apex -DB containers and pluggable databases Many more that I am too lazy to list . All of these come pre packaged with Oracle. If you are in an Organization that has 1000s…

I used ApEx in a previous job. I don't count it as a feature.

Re: Oracle vs. PostgreSQL – A Comment

#187
post #156

Is DB2 dead ?

My company uses it all the time. It's an absolutely rock-solid database and I've never had any issues with it. They just released their new containerized version a few months back and have recently simplified their licensing rather significantly. One of my favorite features is the "time travel" query. If you enable this feature on one or more tables you can essentially say "give the results of this query as it would…

Bitemporalism a la SQL:2011 has been partly or wholly implemented by several RDBMSes at this point. Off the top of my head SQL Server, Oracle and MariaDB have it as well as DB2.

I'm looking forward to seeing it in PostgreSQL.

Re: Oracle vs. PostgreSQL – A Comment

#188
post #3

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…

> any program benchmark tests Don't think installation size or length of time taken to set up the program really qualify as a "program benchmark test", so he should be fine

Would you want to argue about that in court?

Re: Oracle vs. PostgreSQL – A Comment

#189
post #137

Earlier quoted context omitted.

This isn't true. For example: If a user schedules an event to happen at 15:35 on July 29th 2021 IST, you cannot know with certainty what the equivalent UTC value is. You know what it would be assuming the relationship between IST and UTC stays the same between now and next year. If India suddenly decides to implement some sort of DST, or make any other changes to the definition to IST, the UTC value you stored is now…

> If India suddenly decides to implement some sort of DST, or make any other changes to the definition to IST, the UTC value you stored is now wrong. It is not wrong. When timezones change, the database that contains that info is updated - but it still retains information about historical rules, precisely so that earlier dates can still be converted reliably. On the other hand, if you use local times, then you are no…

How are you going to know to look for changes to IST when all you have is a UTC date?

Re: Oracle vs. PostgreSQL – A Comment

#190
post #137

Earlier quoted context omitted.

This isn't true. For example: If a user schedules an event to happen at 15:35 on July 29th 2021 IST, you cannot know with certainty what the equivalent UTC value is. You know what it would be assuming the relationship between IST and UTC stays the same between now and next year. If India suddenly decides to implement some sort of DST, or make any other changes to the definition to IST, the UTC value you stored is now…

> If India suddenly decides to implement some sort of DST, or make any other changes to the definition to IST, the UTC value you stored is now wrong. It is not wrong. When timezones change, the database that contains that info is updated - but it still retains information about historical rules, precisely so that earlier dates can still be converted reliably. On the other hand, if you use local times, then you are no…

[deleted]
Post reply on HN