Re: possible TODO: read-only tables, select from indexes

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