Re: unlogged tables

On Sat, Nov 13, 2010 at 7:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 2. The second one (unlogged-tables-v1) adds support for unlogged
>> tables by adding a new supported value for relpersistence. I made this
>> work by having backend that creates an unlogged relation write out an
>> "init" fork for that relation.  The main fork is nuked and replaced by
>> the contents of the init fork during startup.  But I haven't made this
>> code work yet for index types other than btree, so attempting to
>> define a non-btree index on an unlogged relation will currently result
>> in an error.  I don't think that's probably too hard to fix, but I
>> haven't done it yet.
>
> That seems pretty gross.  If you're going to have to take a special
> action at startup anyway, why wouldn't it take the form of "truncate,
> then if it's an index, call the appropriate ambuild function"?

We've been over this ground before. You can't read from non-shared
catalogs without binding to a database, and you must reinitialize all
unlogged relations before opening the database for a connection. So
what you're proposing would involving launching a worker process for
each database in the cluster, having it do its thing and then exit,
and only after all that's done opening the database for connections.
That seems vastly more complex and less performant than what I've done
here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company