On Thu, 2008-09-18 at 09:57 -0400, Tom Lane wrote:
> I wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >> In some cases, but my wish is also to minimise WAL volume as much as
> >> possible.
>
> > I'm with Greg on this one: baroque bit-squeezing schemes are a bad idea.
>
> Wait a minute ...
On Thu, 2008-09-18 at 08:38 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Thu, 2008-09-18 at 12:40 +0100, Greg Stark wrote:
> >> Why bit just add a new bitfield for flags if we need them? I'm usually
> >> the one worried about data density so perhaps I should be on the
I wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> In some cases, but my wish is also to minimise WAL volume as much as
>> possible.
> I'm with Greg on this one: baroque bit-squeezing schemes are a bad idea.
Wait a minute ... why are we even having this conversation? XLogRecord
has at least t
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Or, we could store only the delta between current record and the
> previous one. Assuming we know what the current record is, that wouldn't
> lose any precision. That way xl_prev only needs to be as big as the
> biggest possible WAL record we can
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2008-09-18 at 12:40 +0100, Greg Stark wrote:
>> Why bit just add a new bitfield for flags if we need them? I'm usually
>> the one worried about data density so perhaps I should be on the other
>> side of the fence here but I'm not sure. The conv
On Thu, 2008-09-18 at 12:40 +0100, Greg Stark wrote:
> Why bit just add a new bitfield for flags if we need them? I'm usually
> the one worried about data density so perhaps I should be on the other
> side of the fence here but I'm not sure. The conventional wisdom is
> that wal bandwidth i
Why bit just add a new bitfield for flags if we need them? I'm usually
the one worried about data density so perhaps I should be on the other
side of the fence here but I'm not sure. The conventional wisdom is
that wal bandwidth is not a major issue.
greg
On 18 Sep 2008, at 12:15, Simon Ri
On Thu, 2008-09-18 at 13:56 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I'd like to add some new flag bits to XLogRecord. (xlog.h)
> >
> > Where? xl_prev.
>
> I'm more curious about "What?" and "Why?", actually ;-),
Just trying to solve the egg/chicken problem of "I want to add a
Simon Riggs wrote:
I'd like to add some new flag bits to XLogRecord. (xlog.h)
Where? xl_prev.
I'm more curious about "What?" and "Why?", actually ;-),
So I would like to propose that we ignore the top 4 bits in
xl_prev.xlogid when comparing values, rather than using all 32 bits for
compariso
I'd like to add some new flag bits to XLogRecord. (xlog.h)
Where? xl_prev.
xl_prev is an XLogRecPtr which points backwards to the immediately
preceeding WAL record. All of the bits are currently used, but I have
some observations and a proposal to change that.
We currently compare the whole xl_p
10 matches
Mail list logo
