> Naturally, there are other compression and delta encoding schemes. Does
> anyone feel the need to explore further alternatives?
>
> We might eventually find the need for multiple, user-selectable, WAL
> compression strategies. I don't recommend taking that step yet.
>
my currently implement
On Tue, Oct 23, 2012 at 08:21:54PM -0400, Noah Misch wrote:
> -Patch- -tps@-c1- -tps@-c2- -tps@-c8- -WAL@-c8-
> HEAD,-F80 816 164465281821 MiB
> xlogscale,-F80 824 164365511826 MiB
> xlogscale+lz,-F80 717 146
On Tue, Oct 23, 2012 at 8:21 PM, Noah Misch wrote:
> -Patch- -tps@-c1- -tps@-c2- -tps@-c8- -WAL@-c8-
> HEAD,-F80 816 164465281821 MiB
> xlogscale,-F80 824 164365511826 MiB
> xlogscale+lz,-F80 717 1466
On Wed, Oct 24, 2012 at 05:55:56AM +, Amit kapila wrote:
> Wednesday, October 24, 2012 5:51 AM Noah Misch wrote:
> > Stepping back a moment, I would expect this patch to change performance in
> > at
> > least four ways (Heikki largely covered this upthread):
>
> > a) High-concurrency workload
On Wednesday, October 24, 2012 12:15 AM Alvaro Herrera wrote:
Amit kapila wrote:
> Rebased version of patch based on latest code.
> Uhm, how can this patch change a caller of PageAddItem() by adding one
> more argument, yet not touch bufpage.c at all? Are you sure this
> compiles?
It compiles,
Wednesday, October 24, 2012 5:51 AM Noah Misch wrote:
>Hi Amit,
Noah, Thank you for taking the performance data.
>On Tue, Oct 16, 2012 at 09:22:39AM +, Amit kapila wrote:
> On Saturday, October 06, 2012 7:34 PM Amit Kapila wrote:
>> > Please find the readings of LZ patch along with Xlog-Scal
Hi Amit,
On Tue, Oct 16, 2012 at 09:22:39AM +, Amit kapila wrote:
> On Saturday, October 06, 2012 7:34 PM Amit Kapila wrote:
> > Please find the readings of LZ patch along with Xlog-Scale patch.
> > The comparison is between for Update operations
> > base code + Xlog Scale Patch
> > base code
Amit kapila wrote:
> Rebased version of patch based on latest code.
Uhm, how can this patch change a caller of PageAddItem() by adding one
more argument, yet not touch bufpage.c at all? Are you sure this
compiles?
The email subject has a WIP tag; is that still the patch status? If so,
I assume
On Thursday, October 04, 2012 8:03 PM Heikki Linnakangas wrote:
On Wednesday, October 03, 2012 9:33 PM Amit Kapila wrote:
On Friday, September 28, 2012 7:03 PM Amit Kapila wrote:
> > On Thursday, September 27, 2012 6:39 PM Amit Kapila wrote:
> > > On Thursday, September 27, 2012 4:12 PM Heikki Linn
> On Thursday, October 04, 2012 12:54 PM Heikki Linnakangas
> On 03.10.2012 19:03, Amit Kapila wrote:
> > Any comments/suggestions regarding performance/functionality test?
>
> Hmm. Doing a lot of UPDATEs concurrently can be limited by the
> WALInsertLock, which each inserter holds while copying t
On 03.10.2012 19:03, Amit Kapila wrote:
Any comments/suggestions regarding performance/functionality test?
Hmm. Doing a lot of UPDATEs concurrently can be limited by the
WALInsertLock, which each inserter holds while copying the WAL record to
the buffer. Reducing the size of the WAL records,
> On Thursday, September 27, 2012 4:12 PM Heikki Linnakangas wrote:
> On 25.09.2012 18:27, Amit Kapila wrote:
> > If you feel it is must to do the comparison, we can do it in same way
> > as we identify for HOT?
>
> Yeah. (But as discussed, I think it would be even better to just treat
> the old a
On 25.09.2012 18:27, Amit Kapila wrote:
If you feel it is must to do the comparison, we can do it in same way as we
identify for HOT?
Yeah. (But as discussed, I think it would be even better to just treat
the old and new tuple as an opaque chunk of bytes, and run them through
a generic delta
On Thursday, September 27, 2012 10:19 AM
> Noah Misch writes:
> > You cannot assume executor-unmodified columns are also unmodified
> from
> > heap_update()'s perspective. Expansion in one column may instigate
> TOAST
> > compression of a logically-unmodified column, and that counts as a
> chan
Noah Misch writes:
> You cannot assume executor-unmodified columns are also unmodified from
> heap_update()'s perspective. Expansion in one column may instigate TOAST
> compression of a logically-unmodified column, and that counts as a change for
> xlog delta purposes.
Um ... what about BEFORE t
On Mon, Sep 24, 2012 at 10:57:02AM +, Amit kapila wrote:
> Rebased version of patch based on latest code.
I like the direction you're taking with this patch; the gains are striking,
especially considering the isolation of the changes.
You cannot assume executor-unmodified columns are also unm
> On Tuesday, September 25, 2012 7:30 PM Heikki Linnakangas wrote:
> On 24.09.2012 13:57, Amit kapila wrote:
> > Rebased version of patch based on latest code.
>
> When HOT was designed, we decided that heap_update needs to compare the
> old and new attributes directly, with memcmp(), to determine
On 24.09.2012 13:57, Amit kapila wrote:
Rebased version of patch based on latest code.
When HOT was designed, we decided that heap_update needs to compare the
old and new attributes directly, with memcmp(), to determine whether any
of the indexed columns have changed. It was not deemed infeas
From: Heikki Linnakangas [mailto:heikki(dot)linnakangas(at)enterprisedb(dot)com]
Sent: Monday, August 27, 2012 5:58 PM
To: Amit kapila
On 27.08.2012 15:18, Amit kapila wrote:
>>> I have implemented the WAL Reduction Patch for the case of HOT Update as
pointed out by Simon and Robert. In this patch
19 matches
Mail list logo
