Re: Performance Improvement by reducing WAL for Update Operation

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Mike Blackwell <mike(dot)blackwell(at)rrd(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>
Subject: Re: Performance Improvement by reducing WAL for Update Operation
Date: 2014-03-04 10:43:48
Message-ID: 5315AE64.5090504@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03/03/2014 04:57 PM, Andres Freund wrote:
> On 2014-03-03 16:27:05 +0200, Heikki Linnakangas wrote:
>> Attached is a rewritten version, which does the prefix/suffix tests directly
>> in heapam.c, and adds the prefix/suffix lengths directly as fields in the
>> WAL record. If you could take one more look at this version, to check if
>> I've missed anything.
>
> Have you rerun the benchmarks?

No.

> I'd guess the CPU overhead of this version is lower than earlier
> versions,

That's what I would expect too.

> but seing it tested won't be a bad idea.

Agreed. Amit, do you have the test setup at hand, can you check the
performance of this one more time?

Also, I removed the GUC and table level options, on the assumption that
this is cheap enough even when it's not helping that we don't need to
make it configurable.

>> This ought to be tested with the new logical decoding stuff as it modified
>> the WAL update record format which the logical decoding stuff also relies,
>> but I don't know anything about that.
>
> Hm, I think all it needs to do disable delta encoding if
> need_tuple_data (which is dependent on wal_level=logical).

That's a pity, but we can live with it. If we did this at a higher level
and checked which columns have been modified, we could include just the
modified fields in the record, which should to be enough for logical
decoding. It might be even more useful for logical decoding too to know
exactly which fields were changed.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2014-03-04 10:44:42 Re: jsonb and nested hstore
Previous Message Oleg Bartunov 2014-03-04 10:37:21 Re: jsonb and nested hstore