Re: [PATCHES] Writing Commit Status hint bits (was Re: [HACKERS] Constant WAL replay)

2005-07-22 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: > In general, the hint bits are good. In *some* cases, not. I still seek > control over that as a designer. > Specifically, the scenario I want to optimize is this: > - we load a table with lots of real time measurement data, as one child > out of a large nu

Re: [PATCHES] Writing Commit Status hint bits (was Re: [HACKERS] Constant WAL replay)

2005-07-20 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: > On Wed, 2005-07-20 at 09:24 -0400, Tom Lane wrote: >> We don't rely on any one write of them to work, but that doesn't mean >> that we can indefinitely postpone writing them. > OK, I think I understand where you're coming from now. Apparently not :-( > W

Re: [PATCHES] Writing Commit Status hint bits (was Re: [HACKERS] Constant WAL replay)

2005-07-20 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: > On Tue, 2005-07-19 at 22:24 -0400, Tom Lane wrote: >> Simon Riggs <[EMAIL PROTECTED]> writes: >>> Short patch enclosed to turn off writing of commit-status hint bits. >> >> Doesn't this entirely destroy the ability to truncate clog, and >> therefore the a

Re: [PATCHES] Writing Commit Status hint bits (was Re: [HACKERS] Constant WAL replay)

2005-07-19 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: > Short patch enclosed to turn off writing of commit-status hint bits. Doesn't this entirely destroy the ability to truncate clog, and therefore the ability to survive XID wraparound? It probably also breaks subxact and multixact logging, but I haven't look