On Tue, Dec 10, 2013 at 5:49 AM, Bill Moran <wmoran@potentialtech.com> wrote:
> 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)
This. mysql (not to bash, but...) has several misfeatures but storage
backends have got to be the worst (query cache would be close second
but at least you can turn that off): it hides the internal details of
the record storage from the query planner and various other SQL level
features such as RI. It's somewhat analogous to *only* having the FDW
API (plus some extensions) to access data.
Very much agree with Kevin: exotic storage can now live there and
that's where you should be looking. It's going to have some severe
constraints relative to what regular tables can do but that should
slowly resolve over time.
merlin
