On Mon, 09 Dec 2013 06:20:41 -1000 Stephan Fabel <sfabel@hawaii.edu> wrote:
> Hi all,
>
> and sorry if I'm asking a question that has been answered before; has the
> PostgreSQL community ever considered different key/value backends (sort of like
> MySQL with its many different options)?
>
> We'd be very interested in seeing the effects of integrating LMDB [*] in terms
> of performance gains. Has this avenue been explored before?
I have to say that I'm VERY happy that there's been little to no focus on
supporting different backend storage in PostgreSQL.
I am forced to manage a significant amount of data in MySQL. The number of
restrictions in MySQL and the number of problems with MySQL that I can
either directly or indirectly attribute to the decision to support multiple
storage backends is phenominal. In my opinion, MySQL has far too much of
a seperation betweeen MySQL itself and it's engines (innodb being the most
common). This has resulted in:
* Overly complex configuration
* Performance issues
* Overly complex diagnosis of performance issues
* A brittle, unreliable system
* Outright broken features (such as transactions that aren't guaranteed to
be transactional)
For me, this is a database system, not a reality TV show. I'd much rather
have the focus stay on a tightly integrated, reliable system than have a
bunch of weird choices that can improve my performance by .5% while causing
unexpected breakage.
As an example, the ARCHIVE engine in MySQL is frequently touted as being
much more efficient storage than innodb, but it does this at the loss of
indexing, foreign keys, and transactional integrety. Why don't the MySQL
developers take time to make innodb's compression work better (it's horrible
at this time) instead of creating a completely different engine that throws
away important fuctionality?
I suspect this is part of the reason the PG developers have avoided making
dozens of storage engines and instead focused on making the one that we
have the best one possible.
--
Bill Moran <wmoran@potentialtech.com>