Re: unlogged tables vs. GIST

On Fri, Dec 17, 2010 at 3:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Yeah.  I think that BM_UNLOGGED might be a poor choice for the flag name,
>>> just because it overstates what the bufmgr needs to assume.
>
>> I was actually thinking of adding BM_UNLOGGED even before this
>> discussion, because that would allow unlogged buffers to be excluded
>> from non-shutdown checkpoints.  We could add two flags with different
>> semantics that take on, under present rules, the same value, but I'd
>> be disinclined to burn the extra bit without a concrete need.
>
> bufmgr is currently using eight bits out of a 16-bit flag field, and
> IIRC at least five of those have been there since the beginning.  So our
> accretion rate is something like one bit every four years.  I think not
> being willing to use two bits to describe two unrelated behaviors is
> penny-wise and pound-foolish --- bufmgr is already complicated enough,
> let's not add useless barriers to readability.

Allright, what do you want to call the other bit, then? BM_SKIP_XLOG_FLUSH?

I have a feeling we may also be creating BM_UNTIDY rather soon, per
previous discussion of hint bit I/O.

Since these bits will only be set/cleared when the buffer mapping is
changed, can we examine this bit without taking the spinlock? If not,
we're going to have to stick an extra spinlock acquire/release into
FlushBuffer(), which sounds rather unappealing.

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