4 ms·

It doesn't have pluggable-storage-engines. Postgresql is working with bidirectional replication (master-master).

rcoder 12y ago
Re: storage engines, my apologies; those mean something very specific in the MySQL world and the more appropriate term for Postgres-land would be foreign data wrappers. I stand by my point about flexibility regardless.
keeperofdakeys 12y ago
What's the purpose of having pluggable-storage-engines? From what I can see, InnoDB is the only engine to support basic features like transactions, foreign-keys, MVCC, etc. I'm sure there are reasons to use the other storage-engines, like MyISAM for archiving lots of data, but why not just use a different database for this? Is there a performance price for having this flexibility?
- ddorian43 12y ago
  Yeah mysql-implementation sucks. And (from reading the discussions on pg-hackers) was that it's very hard to keep semantics (transactions, snapshot-isolation, indexes etc). Different storage-engines have different pros-cons (the same with indexes gin/gist). You could have: in-memory storage engine (ex: current unlogged tables don't replicate since they don't have wal) compressed (something like tokudb/mx) columnar (see monetdb vs citus) etc It's harder to use another database because maintance + flexibility (ex: postgresql has arrays).
  - tomiko_nakamura 12y ago
    People are working on other storage types for PostgreSQL. That's all I can say at this moment.
    - ddorian43 12y ago
      Strange that they are working in secrecy. I would guess something like[1] would be better. [1]: http://www.postgresql.org/message-id/CA+U5nM+AFftDf-8UaMoe7Z8W6Sx-2EjFvEHephKQ=doEQ2Y1nQ@mail.gmail.com http://www.postgresql.org/message-id/CA+U5nM+AFftDf-8UaMoe7Z...
    - ddorian43 12y ago
      Maybe you meant about this ? http://www.datanami.com/2015/03/04/fujitsu-adding-column-oriented-processing-engine-to-postgresql/ http://www.datanami.com/2015/03/04/fujitsu-adding-column-ori...
- dragonwriter 12y ago
  > why not just use a different database for this? You effectively are using different databases (as far as, e.g., operational characteristics) but with a common interface presented to client apps, letting the visibile database engine serve as an abstraction layer, and the consuming app(s) don't need to be aware of the backend differences, and are also somewhat insulated against needing to change if the storage engine used for various pieces changes.
- deleted 12y ago
  [deleted]
tomiko_nakamura 12y ago
It doesn't have MySQL-like pluggable storage, and frankly I'm thankful for that. How many of the MySQL storage engines actually work, including transactions for queries working with tables using different storage engines and such? Or support all the features like fulltext, and so on? Whenever I want to get scared at night, I either watch the first "Alien" movie or read "MySQL restrictions and limitations". So no, thank you very much. OTOH, PostgreSQL code base is one of the cleanest and well structured code bases I've seen, and adding a new storage engine is not all that complicated, assuming you know what you're doing and have time to do that properly. If you just want something simple, managed outside but accessed by SQL, use FDW.

Re: storage engines, my apologies; those mean something very specific in the MySQL world and the more appropriate term for Postgres-land would be foreign data wrappers. I stand by my point about flexibility regardless.

keeperofdakeys 12y ago

What's the purpose of having pluggable-storage-engines? From what I can see, InnoDB is the only engine to support basic features like transactions, foreign-keys, MVCC, etc. I'm sure there are reasons to use the other storage-engines, like MyISAM for archiving lots of data, but why not just use a different database for this? Is there a performance price for having this flexibility?

ddorian43 12y ago
Yeah mysql-implementation sucks. And (from reading the discussions on pg-hackers) was that it's very hard to keep semantics (transactions, snapshot-isolation, indexes etc). Different storage-engines have different pros-cons (the same with indexes gin/gist). You could have: in-memory storage engine (ex: current unlogged tables don't replicate since they don't have wal) compressed (something like tokudb/mx) columnar (see monetdb vs citus) etc It's harder to use another database because maintance + flexibility (ex: postgresql has arrays).
- tomiko_nakamura 12y ago
  People are working on other storage types for PostgreSQL. That's all I can say at this moment.
  - ddorian43 12y ago
    Strange that they are working in secrecy. I would guess something like[1] would be better. [1]: http://www.postgresql.org/message-id/CA+U5nM+AFftDf-8UaMoe7Z8W6Sx-2EjFvEHephKQ=doEQ2Y1nQ@mail.gmail.com http://www.postgresql.org/message-id/CA+U5nM+AFftDf-8UaMoe7Z...
  - ddorian43 12y ago
    Maybe you meant about this ? http://www.datanami.com/2015/03/04/fujitsu-adding-column-oriented-processing-engine-to-postgresql/ http://www.datanami.com/2015/03/04/fujitsu-adding-column-ori...
dragonwriter 12y ago
> why not just use a different database for this? You effectively are using different databases (as far as, e.g., operational characteristics) but with a common interface presented to client apps, letting the visibile database engine serve as an abstraction layer, and the consuming app(s) don't need to be aware of the backend differences, and are also somewhat insulated against needing to change if the storage engine used for various pieces changes.
deleted 12y ago
[deleted]

tomiko_nakamura 12y ago

It doesn't have MySQL-like pluggable storage, and frankly I'm thankful for that. How many of the MySQL storage engines actually work, including transactions for queries working with tables using different storage engines and such? Or support all the features like fulltext, and so on? Whenever I want to get scared at night, I either watch the first "Alien" movie or read "MySQL restrictions and limitations". So no, thank you very much. OTOH, PostgreSQL code base is one of the cleanest and well structured code bases I've seen, and adding a new storage engine is not all that complicated, assuming you know what you're doing and have time to do that properly. If you just want something simple, managed outside but accessed by SQL, use FDW.