From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: unlogged tables vs. GIST |
Date: | 2010-12-17 19:07:22 |
Message-ID: | 3753.1292612842@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Given the foregoing discussion, I see only two possible paths forward here.
> 1. Just decide that that unlogged tables can't have GIST indexes, at
> least until someone figures out a way to make it work. That's sort of
> an annoying limitation, but I think we could live with it.
> 2. Write WAL records even though the GIST index is supposedly
> unlogged. We could either (1) write the usual XLOG_GIST_* records,
> and arrange to ignore them on replay when the relation in question is
> unlogged, or (2) write an XLOG_NOOP record to advance the current LSN.
> The latter sounds safer to me, but it will mean that the XLOG code
> for GIST needs three separate cases (temp, perm, unlogged). Either
> way we give up a significant chunk of the benefit of making the
> relation unlogged in the first place.
> Thoughts?
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-12-17 19:08:15 | Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?) |
Previous Message | Alex Hunsaker | 2010-12-17 19:07:11 | Re: plperlu problem with utf8 |