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
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
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
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
On Sun, 2005-04-24 at 02:28 -0400, Tom Lane wrote:
> In the current code there is no such thing as a hard read-only behavior
> --- for example we will try to update commit-status hint bits no matter
> what. Allowing that to be turned off would be interesting for a number
> of purposes, such as bur