From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [WIP] The relminxid addition, try 3 |
Date: | 2006-05-08 20:46:29 |
Message-ID: | 29645.1147121189@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> (Now, if you're combining this with the very grotty relpages/reltuples
>> update code, then I'm all for making that xlog properly --- we've gotten
>> away without it so far but it really should xlog the change.)
> I hadn't done that, but I'll see what I can do. Notice however that I'm
> doing this in both pg_class _and_ pg_database.
It strikes me that the cleanest way to deal with this is to invent a
single new type of xlog record, something like HEAP_UPDATE_IN_PLACE,
which just replaces tuple contents with a new tuple of the same size.
This would serve for both stats updates and unfreezing in both pg_class
and pg_database, and might have other uses in future for
non-transactional updates. It's a little bit more xlog space than your
unfreeze-specific operations, but I don't think we need to sweat a few
bytes for those; they're not likely to be common.
Barring objections, I'll add this when I refactor UpdateStats. Got some
other work I need to get back to right now, though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2006-05-08 21:21:33 | Re: Page at a time index scan |
Previous Message | Magnus Hagander | 2006-05-08 20:38:37 | Re: Building with Visual C++ |