On Mon, Sep 13, 2010 at 5:24 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> The LSNs on all pages in an unlogged relation should be zero, and
> XLogFlush() will do nothing. That's what we rely on at the moment for pages
> that are not WAL-logged for some reason, I don't think you need any extra
> flag for that.
Ah, interesting. I wonder if I should add a cross-check for that and
elog(LOG) if it isn't the case, or some such.
>> So I went looking for bit-space in the buffer tag and quickly found
>> some. ForkNumber is an enum which I suppose means a 32-bit integer,
>> but we've only got three forks right now and it's hard to imagine more
>> than a handful of additional ones, so what I'm tempted to do is change
>> this from an enum to a 2-byte integer and replace the enum values with
>> #defines. That frees up 2 bytes in the buffer tag which is more than
>> plenty.
>
> I haven't been following the discussion so I don't understand why you need
> the extra bits, but no objections to reducing the fork number field.
Well, the idea is that unlogged table files are named differently than
regular table files (I'm thinking, just insert a "u" at the beginning)
so that we can truncate them at startup time without needing to look
at any catalog entries. So the point is you could have
data/base/16384/u124141421 block 173 and data/base/16384/124141421
block 173 in the buffer cache at the same time. The alternative is
to try to make sure that you never create both of those files in the
first place, but that requires an extra system call per
GetNewRelFileNode() - and that could get worse in the future if for
some reason we find it advantageous to have more than two
"namespaces". (The already-committed RelFileNodeBackend patch already
creates one "namespace" per backend for temporary tables plus one for
permanent tables; but that doesn't run into this problem because
temporary tables use backend-local buffers - i.e. the relevant
BackendId can be inferred strictly from which set of buffers we're
looking at.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company