Re: unlogged tables vs. GIST

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: unlogged tables vs. GIST
Дата
Msg-id AANLkTi=w+Qpw40-8eFewtthPsGmt5gCNXOYePpnd-Sse@mail.gmail.com
обсуждение исходный текст
Ответ на Re: unlogged tables vs. GIST  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: unlogged tables vs. GIST  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Dec 17, 2010 at 2:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> IIUC, the problem is that the bufmgr might think that a GIST NSN is an
> LSN that should affect when to force out a dirty buffer?  What if we
> taught it the difference?  We could for example dedicate a pd_flags
> bit to marking pages whose pd_lsn isn't actually an LSN.
>
> This solution would probably imply that all pages in the shared buffer
> pool have to have a standard PageHeaderData header, not just an LSN at
> the front as is assumed now.  But that doesn't seem like a bad thing to
> me, unless maybe we were dumb enough to not use a standard page header
> in some of the secondary forks.

Ah, interesting idea.  visibilitymap.c has this:

#define MAPSIZE (BLCKSZ - MAXALIGN(SizeOfPageHeaderData))

and fsm_internals.h has this:

#define NodesPerPage (BLCKSZ - MAXALIGN(SizeOfPageHeaderData) - \
offsetof(FSMPageData,fp_nodes)) 

...which seems to imply, at least on a quick look, that we might be
OK, as far as the extra forks go.

I have a vague recollection that the documentation says somewhere that
a full page header on every page isn't required.  And I'm a little
worried about my ability to track down every place in the system that
might get broken by a change in this area.  What do you think about
committing the unlogged tables patch initially without support for
GIST indexes, and working on fixing this as a separate commit?

Another possibly-useful thing about mandating a full page header for
every page is that it might give us a way of avoiding unnecessary full
page writes.  As I wrote previously:

> However, I think we can avoid this too, by
> allocating an additional bit in pd_flags, PD_FPI.  Instead of emitting
> an FPI when the old LSN precedes the redo pointer, we'll emit an FPI
> when the FPI bit is set (in which case we'll also clear the bit) OR
> when the old LSN precedes the redo pointer.  Upon emitting a WAL
> record that is torn-page safe (such as a freeze or all-visible
> record), we'll pass a flag to XLogInsert that arranges to suppress
> FPIs, bump the LSN, and set PD_FPI.  That way, if the page is touched
> again before the next checkpoint by an operation that does NOT
> suppress FPI, one will be emitted then.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ps_status on fastpath
Следующее
От: Tom Lane
Дата:
Сообщение: Re: unlogged tables vs. GIST