2. Simple tables can be much smaller since you don't need
most of the HeapTupleHeaderData.
What you are talking about is not a "read only" table, it is a "non-MVCC" table. This is a much greater assault on the fundamental semantics of Postgres than it's being painted to be in this thread. In particular, how is such a table going to come into being? You'd not be able to just flip the READ-ONLY flag on and off.
I can see it now....
Nov 21, 2005: Earlier today, the PostgreSQL Global Development group issued a press release announcing the availability of PostMySQL 10g. PostMySQL 10g continues PostgreSQL's venerable legacy of doing things the Right Way, but brings great performance enhancements to read-only or light-update loads through the introduction of PostMyISAM tables. PostMyISAM tables are eagerly awaited by the data warehousing community because of their more compact on-disk representation and because their lack of tuple visibility information allows queries to be answered directly from the index.
The move is widely seen as an effort to gain market share at the expense of MySQL. MySQL AB CEO Marten Mickos was quick to point out that the new features made PostgreSQL much more like MySQL, but that their implementation had serious flaws.
"Their [PostMySQL's] implementation is nearly useless in an enterprise OLAP environment. ... In a double-blind test of the two systems, users preferred the mature MySQL implementation that does the Best Thing Under the Circumstances (tm) rather than PostMySQL's fixation with data integrity. While attempting to load the sample data before running benchmarks the user found in 'unbelievably' slow. After consulting with PostgreSQL experts, the user was instructed to tune various default configuration parameters and wrap the inserts in a transaction. After doing so, the loading proceeded at a reasonable speed.
"However, it was discovered that one of the records in the 120 gigabyte import data had February 29, 2003 stored in a date field. The PostMySQL database engine refused to store this date, and rolled the entire inserting transaction back. Apparently this is a non-trivial action for the PostMyISAM tables, as after 15 minutes the user thought that the database had locked up and terminated the postmaster process, causing more trouble when the database would not start. [Editor's comment: the corruption was blamed on a bug introduced during the somewhat hasty rewrite of the entire PostgreSQL code base in C++.] After doing initdb again and editing the import data by hand, the user managed to load the data.
"In conclusion, ... the new PostMyISAM tables negate all of PostMySQL's claimed ACIDity and concurrency benefits, while we [MySQLAB] offer a mature, stable implementation that requires much less work to configure, is more flexible and forgiving of the surprises found in real-world databases, and enjoys a much larger user community and comprehensive suite of 3rd party tools."
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
