Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL Rising

wekeroad.com

Post reply on HN
Print view View original

91–100 of 204 posts

Re: PostgreSQL Rising

#91

Post by justincormack »

rickmb wrote: post #84

The primary target audience for hacker-to-hacker Postgres evangelism is MySQL users. Because let's face it, the choice for DBs like Oracle is usually made upstairs, and for very different reasons. So why do Postgres advocates insist on dissing MySQL with false and misleading arguments? The usual target is some default settings, when obviously there are three kinds of MySQL users: the ones that actually have a reason…

It is a lot easier to convince someone who wants to use Oracle to use Postgres than to use Mysql. There is serious commercial support available, and it is built for reliability.

Re: PostgreSQL Rising

#92

Post by yread »

sandGorgon wrote: post #82
jeffdavis wrote: post #77

Earlier quoted context omitted.

"it's a matter of reducing the complexity of migration" You put the code in your application so you can switch out the database, but why do you want to switch databases? You can't switch out the database for one with more features, because then you're not using the lowest common denominator any more, and you can't switch back. It can't be licensing costs, because postgresql licenses are free. The only other reason I…

One reason if you are building a shippable product that needs to work with a variety of client databases rather than a choice of your own. 99% of the time, this is why you build DB agnostic apps.

I am building a product that can work with SQL Server, MySQL, PgSQL and Oracle. The reason was if the company who buys the software already has the infrastructure and DBAs in that database, they can leverage it. If I were making the decision now I would definitely choose just one and stick with it, because

- astonishing amount of things are done differently on these four dbms (idenities/sequences and getting their last value, paging, DDL)

- each of these dbms has specific features which would improve the performance or help us develop stuff but we can't use them because they require different architecture (and we want to keep it the same)

Don't do software for multiple databases. It's just not worth the trouble.

Re: PostgreSQL Rising

#93

Post by jeltz »

justincormack wrote: post #91
rickmb wrote: post #84

The primary target audience for hacker-to-hacker Postgres evangelism is MySQL users. Because let's face it, the choice for DBs like Oracle is usually made upstairs, and for very different reasons. So why do Postgres advocates insist on dissing MySQL with false and misleading arguments? The usual target is some default settings, when obviously there are three kinds of MySQL users: the ones that actually have a reason…

It is a lot easier to convince someone who wants to use Oracle to use Postgres than to use Mysql. There is serious commercial support available, and it is built for reliability.

And there is also a company dedicated to providing a migration path from Oracle to PostgreSQL: EntrepriseDB. I have not used their products but they employ several of the core contributors to the PostgreSQL project which have contributed to many important features.

Re: PostgreSQL Rising

#94

Post by jfaucett »

rickmb wrote: post #84

The primary target audience for hacker-to-hacker Postgres evangelism is MySQL users. Because let's face it, the choice for DBs like Oracle is usually made upstairs, and for very different reasons. So why do Postgres advocates insist on dissing MySQL with false and misleading arguments? The usual target is some default settings, when obviously there are three kinds of MySQL users: the ones that actually have a reason…

I couldn't agree with you more. The statements made in this article seem pretty derisive towards MySQL, a system I like for its flexability, easy integration, and power. Sure, it might not be the most pure sql implementation, it lets you bend the rules for data integrity (maybe not best practice but I still like it) and there are some quirks but calling MySQL stupid doesn't make me a Postgres fan.

Re: PostgreSQL Rising

#95

Post by yorhel »

davyjones wrote: post #81

I would really appreciate it folks can try out my free and open source GUI client for postgres: http://pgXplorer.com . It is available for Mac, Ubuntu (64) and Windows (64).

Just tried to compile from git, but the qt-psql requirement wasn't very easy to satisfy on Arch. Your Ubuntu binary worked fine.

Looks quite nice, and there certainly is a need for more PostgreSQL GUIs. Some feedback from the minute I used it:

- You don't handle bytea columns very nicely. I'd expect those to be displayed in hex or so.

- Browsing a table is very slow on tables with large columns. I was testing on a table with a ~10KiB text column.

- I personally prefer a more compact interface, having an option for smaller buttons would be a good start. :-)

(Edit: formatting)

Re: PostgreSQL Rising

#96

Post by jeltz »

zzzeek wrote: post #48
rosser wrote: post #30

Earlier quoted context omitted.

I mentioned something about this the last time a discussion involving Django and Postgres came up, but it bears repeating. If your environment is set up such that database connections are long-lived, please double-check that you're not using SQLAlchemy's default behavior to open an explicit transaction (e.g., "BEGIN TRANSACTION") upon connection. (It may no longer be the default, but it was last I worked with a Djang…

wow, where to begin with the factual errors in this post - most of this post is incorrect. Just to get it out of the way, SQLAlchemy does not emit the "BEGIN" statement, nor does it call any kind of database function that directly emits "BEGIN", ever . Feel free to grep for it, start at version 0.1.0 and go all the way up to the 0.8 tip - you won't see it. It's not a default, it's nothing SQLAlchemy has any kind of o…

> To put it simply, VACUUM has no problems with connections being open. What you're thinking of here are locks, and locks only occur once you're in a transaction and have accessed some table rows, which are now subject to various isolation rules.

I think you are correct except about this. What he is thinking about is indeed as he said transactions. Locks in PostgreSQL do also interfere with VACUUM but that is seldom the problem in practice since locks are usually taken at the row level and reading rows does not require any row locks. Open transactions are the main culprit when it comes to vacuum problems and it does not matter much if they have taken locks or not.

Re: PostgreSQL Rising

#97

Post by jeltz »

juiceandjuice wrote: post #2

I'd love to move away from Oracle to Postgres, I really would. I'm trying to. But for massive amounts of data the partitioning and some other features of Oracle just work better. The partitioning is a huge thing, especially for our data which is partitioned by week then organized according to a hierarchical triangular mesh with bitmapped indexes. This works so well for us (at 8 billion rows) it's silly. MySQL couldn'…

While your partitioning scheme should be implementable in PostgreSQL using table inheritance I do not doubt it is simpler to manage in Oracle. The PostgreSQL partitioning is lacking in usability and also a bit in features.

Re: PostgreSQL Rising

#98

Post by arjn »

My opinion is contrary to most of the comments here. About a year ago we switched a multi-tiered app from MySQL/MSSqlServer to Postgres/Postgres. While everything works fine, after months of using it I find writing programs for and with MySql or MSSqlServer seems easier. One specific complaint I have is that there is no transaction control within pgsql stored procedures (functions). I had to kludge the db link module to get transactions to work. Another related complaint is the DB Link module has poor functionality when compared to MSSqlServer's DB Link. I brought this up yesterday at the PostGres booth at OSCON and they said they're aware of it. No news on when they'll get around to fixing it.

A feature we miss is MySql's ability to use different DB engines such as Archive or Memory. AFAIK there is no equivalent to these in Postgres. We put mysql's Archive engine to good use before we migrated our app. Now we have to export data to gz files via script.

In general I don't think there is a strong reason for the majority of apps to switch to Postgres when MySql works for most needs. (I should mention that pgsql has some nice locking functions that we found useful)

Re: PostgreSQL Rising

#99

Post by pjmlp »

reidrac wrote: post #85
pjmlp wrote: post #79

Earlier quoted context omitted.

I imagine you don't do business in the enterprise world.

Yes, I do. I said "in my experience" and I totally understand why Heruku is offering PostgreSQL and not DB2, Oracle or SQL Server as a service. Amazon RDS started with MySQL, and only two years later Oracle support was added. SQL Server three years later.

Sorry about that, should have read better your comment.

On my area of work we also do a lot of open source, but most customers won't think twice about using proprietary database solutions, specially taking into consideration the types of deployments we do.

In my career in the enterprise world, I've mostly used Oracle, Informix, DB2, Microsoft SQL Server, Sybase SQL Server.

The only two project I used MySQL so far, one was for a prototype application, to be shown in computer fairs. The other was an online survey.

Re: PostgreSQL Rising

#100

Post by jeltz »

yread wrote: post #92
sandGorgon wrote: post #82

Earlier quoted context omitted.

One reason if you are building a shippable product that needs to work with a variety of client databases rather than a choice of your own. 99% of the time, this is why you build DB agnostic apps.

I am building a product that can work with SQL Server, MySQL, PgSQL and Oracle. The reason was if the company who buys the software already has the infrastructure and DBAs in that database, they can leverage it. If I were making the decision now I would definitely choose just one and stick with it, because - astonishing amount of things are done differently on these four dbms (idenities/sequences and getting their la…

Not to mention even the basic data types are differently named and work differently (text vs varchar vs nvarchar vs varchar2). It is especially hard to when you have to work with date and time types/functions.
Post reply on HN