Thread: Information about storge engine in PostgreSQL
Hello MySQL has information about several storage engines. MEMORY to handle temporary tables, InnoDB to handle transactions and which also can split its table data over several files/partitions. Splitting of storage is something which according to the following article, PostgreSQL does not support: http://www.devx.com/dbzone/Article/20743 But I cannot verify this due to lack of information. I haven't found any similar information about the storage engine used by PostgreSQL which I think is called Postgres. Do you know of any places where this information can be obtained? Thank you.
PostgreSQL uses it's own internal storage engine. It doesn not support multiple one. As for splitting files accross partitions this is a feature of version 8.0 called tablespaces. http://developer.postgresql.org/docs/postgres/manage-ag-tablespaces.html Should get you pointed in the right direction. On Thu, 21 Oct 2004 16:27:24 +0200 (CEST), nd02tsk@student.hig.se <nd02tsk@student.hig.se> wrote: > Hello > > MySQL has information about several storage engines. MEMORY to handle > temporary tables, InnoDB to handle transactions and which also can split > its table data over several files/partitions. Splitting of storage is > something which according to the following article, PostgreSQL does not > support: > > http://www.devx.com/dbzone/Article/20743 > > But I cannot verify this due to lack of information. I haven't found any > similar information about the storage engine used by PostgreSQL which I > think is called Postgres. > > Do you know of any places where this information can be obtained? > > Thank you. > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
On Thu, Oct 21, 2004 at 04:27:24PM +0200, nd02tsk@student.hig.se wrote: > Hello > > MySQL has information about several storage engines. I think you will find fairly broad agreement around here that the idea of different storage engines for different jobs is a bad one. But to answer your question. . . > its table data over several files/partitions. Splitting of storage is > something which according to the following article, PostgreSQL does not > support: > > http://www.devx.com/dbzone/Article/20743 In 8.0 (now in beta) that is false. The feature you're looking for is called tablespaces. What PostgreSQL does _not_ have at the moment is the distributed ("multi-master") storage that MySQL is offering. When PostgreSQL delivers that (it's on my department's TODO list this year, FWIW: Jan Wieck is working on it), we'll do so without the sorts of (IMHO dangerous) failure modes that are present in the MySQL offering. > similar information about the storage engine used by PostgreSQL which I > think is called Postgres. There isn't really a separable "storage engine" in PostgreSQL. Depending on whom you ask, "Postgres" is either a short form of PostgreSQL, an ancestor of PostgreSQL, or both. > Do you know of any places where this information can be obtained? Here :) A -- Andrew Sullivan | ajs@crankycanuck.ca I remember when computers were frustrating because they *did* exactly what you told them to. That actually seems sort of quaint now. --J.D. Baldwin
nd02tsk@student.hig.se wrote: > Hello > > MySQL has information about several storage engines. MEMORY to handle > temporary tables, InnoDB to handle transactions and which also can split > its table data over several files/partitions. Splitting of storage is > something which according to the following article, PostgreSQL does not > support: > > http://www.devx.com/dbzone/Article/20743 > > But I cannot verify this due to lack of information. I haven't found any > similar information about the storage engine used by PostgreSQL which I > think is called Postgres. PostgreSQL has one and only one storage engine. Unless you intend working on the source-code of PostgreSQL itself there's no point in enquiring about its details. A database is already split over several files, and individual objects (tables/indexes) may be split into multiple files of 1GB each. You can spread the load over multiple drives via various RAID setups, symlinks or, in 8.0 tablespaces. HTH PS - treat most articles you read on the web with some caution. Most are poorly researched by people without the experience to write their topic. I haven't read the article linked above. -- Richard Huxton Archonet Ltd
> Splitting of storage is > something which according to the following article, PostgreSQL does not > support: > > http://www.devx.com/dbzone/Article/20743 > > But I cannot verify this due to lack of information. Hm. How about reading the standard PostgreSQL documentation ? It at least depends on your definition of "Splitting of storage". > Do you know of any places where this information can be obtained? My guess would be the docs at the postgresql website. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
On 10/21/2004 10:27 AM, nd02tsk@student.hig.se wrote: > Hello > > MySQL has information about several storage engines. MEMORY to handle > temporary tables, InnoDB to handle transactions and which also can split > its table data over several files/partitions. Splitting of storage is > something which according to the following article, PostgreSQL does not > support: For a long time the MySQL documentation was stating that foreign keys are mainly for documentation purposes and explained why you really didn't want them and why it was so much better that MySQL swallowed their syntax silently without any effect. Similarly dangerous opinions where documented about transactions and ACID features. Then the InnoDB table handler was added to MySQL and with the new features, namely transactions and referential integrity, the documented opinion about these features was changed. But since every other database had these features for long already, all that was left was now the capability of having different storage engines, and it became the new advantage feature to point out. Right now on their boiler plate is another buzzword compliant table handler, the NDB cluster storage engine. And while a lot of people are getting all excited about it, all I really see so far is yet another table handler that does not provide foreign keys, that does not integrate with the existing transaction systems ACID properties, and that has outrageous network and memory requirements. Especially worried am I about the fact that the responsibility for referential integrity, that was lifted from the developers shoulders with the InnoDB tables, is now dropped twice as heavy back into his laps. I don't think that Web developers who had problems getting integrity constraints implemented in the application before InnoDB will do this much better in a concurrent multimaster cluster environment. But I am sure enough PHB's who, free from every knowledge obstacles, fully believe in marketing speech will force their developers into that nightmare. None of all these advanced storage engines was developed by MySQL. They all got purchased and turned into table handlers. The multiple storage engine capability of MySQL is the technical base for stapling together those features, MySQL isn't able to build into the existing system and has to buy somewhere else. The PostgreSQL philosophy is a little different. That is why we have only one, tightly integrated and not very easy to replace storage engine. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
I really appreciate these type of high-quality anwsers, thank you. Tim > On 10/21/2004 10:27 AM, nd02tsk@student.hig.se wrote: > >> Hello >> >> MySQL has information about several storage engines. MEMORY to handle >> temporary tables, InnoDB to handle transactions and which also can split >> its table data over several files/partitions. Splitting of storage is >> something which according to the following article, PostgreSQL does not >> support: > > For a long time the MySQL documentation was stating that foreign keys > are mainly for documentation purposes and explained why you really > didn't want them and why it was so much better that MySQL swallowed > their syntax silently without any effect. Similarly dangerous opinions > where documented about transactions and ACID features. > > Then the InnoDB table handler was added to MySQL and with the new > features, namely transactions and referential integrity, the documented > opinion about these features was changed. But since every other database > had these features for long already, all that was left was now the > capability of having different storage engines, and it became the new > advantage feature to point out. > > Right now on their boiler plate is another buzzword compliant table > handler, the NDB cluster storage engine. And while a lot of people are > getting all excited about it, all I really see so far is yet another > table handler that does not provide foreign keys, that does not > integrate with the existing transaction systems ACID properties, and > that has outrageous network and memory requirements. Especially worried > am I about the fact that the responsibility for referential integrity, > that was lifted from the developers shoulders with the InnoDB tables, is > now dropped twice as heavy back into his laps. I don't think that Web > developers who had problems getting integrity constraints implemented in > the application before InnoDB will do this much better in a concurrent > multimaster cluster environment. But I am sure enough PHB's who, free > from every knowledge obstacles, fully believe in marketing speech will > force their developers into that nightmare. > > None of all these advanced storage engines was developed by MySQL. They > all got purchased and turned into table handlers. The multiple storage > engine capability of MySQL is the technical base for stapling together > those features, MySQL isn't able to build into the existing system and > has to buy somewhere else. > > The PostgreSQL philosophy is a little different. That is why we have > only one, tightly integrated and not very easy to replace storage engine. > > > Jan > > -- > #======================================================================# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #================================================== JanWieck@Yahoo.com # >