Re: possible TODO: read-only tables, select from indexes - Mailing list pgsql-hackers

>>  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."