Re: unlogged tables vs. GIST
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, pgsql-hackers@postgresql.org
Date: 2010-12-17T20:08:07Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
The GiST scan algorithm uses LSNs to detect concurrent pages splits, but
- 2edc5cd493ce 9.1.0 cited
On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >> On 17.12.2010 21:32, Robert Haas wrote: >>> I guess the question is whether it's right to conflate "table is >>> unlogged" with "LSN is fake". It's not immediately obvious to me that >>> those concepts are isomorphic, although though the reverse isn't >>> obvious to me either. > >> The buffer manager only needs to know if it has to flush the WAL before >> writing the page to disk. The flag just means that the buffer manager >> never needs to do that for this buffer. You're still free to store a >> real LSN there if you want to, it just won't cause any WAL flushes. > > 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. It might be > better to reverse the flag sense, and have a new flag that *is* set if > the page contains an LSN that we have to check against WAL. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company