ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
back «  1  2  3 

Re: Where is MySQL ahead of PostgreSQL

"And its interesting that you mention Memcache. There is a storage engine that can work as an interface to Memcache too. "

Hm, how does it map Memcached to relations? PostgreSQL already has the pgmemcache plugin (http://pgfoundry.org/projects/pgmemcache/), but it's not relational -- you just get and set keys like you would with any client.

"I was under the impression that MyISAM stores everything along with the rest of the row data."

Well, a row in MySQL is limited to 64KB. They *have* to store it elsewhere. From the MySQL 5.1 manual: "Each BLOB or TEXT value is represented internally by a separately allocated object. This is in contrast to all other data types, for which storage is allocated once per column when the table is opened." InnoDB internally does not have a 64KB limit, but MySQL enforces it.

The PostgreSQL row limit is nearly 2GB (each row is stored in several chunks internally).

As for the why and wherefores of blobs: In MySQL it makes sense to distinguish between blobs and ordinary columns, since they have different performance characteristics. In PostgreSQL it's all the same. For example, I use the "text" data type for all text; there's absolutely no need to use "varchar" or "char" in PostgreSQL, since the storage requirements are the same, and performance is identical. In this sense "varchar" is de facto a legacy type that's discouraged in modern use. I love being able to store tons of stuff and never worry about any limitations.

Your point about more row data resulting in more I/O is completely valid, of course. You need to make this decision when designing your application and setting up the schema. For example, if you have a table of comments, it's reasonable that most queries will be fetching the comment body text along with everything else. But if you have a database of very long articles that you want to query by metadata, it makes sense to move the text aside in a separate table. But that's an application-level decision, not something that a database should decide; with MySQL you don't have much choice, at least if you're inflicting MyISAM upon yourself.

Merge would definitely be nice. I have been hoping for WAL-based replication for some time, and it looks like they're finally getting their heads out of their asses for this.

«  1  2  3