On Sat, May 31, 2014 at 3:51 AM, Jeff Janes <jeff.janes@gmail.com> wrote: > On Thu, May 29, 2014 at 8:15 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> On Thu, May 29, 2014 at 10:09 PM, Jeff Janes <jeff.janes@gmail.com> wrote: >> > >> > What features in 9.4 need more beta testing for recovery? >> >> Another feature which have interaction with recovery is reduced WAL >> for Update operation: >> http://www.postgresql.org/message-id/E1WNqjM-0003cz-EL@gemulon.postgresql.org >> >> Commit: a3115f > > > It looks like this is something which is "always on", so it should be getting a good test without me taking any special steps. But is there some way, for example something in xlogdump, to assess how often this is getting activated?
Currently there is no simple way to get this information, but with
attached simple patch you can get this information by pg_xlogdump.
It will give you information in below way:
rmgr: Heap len (rec/tot): 47/ 79, tx: 690, lsn: 0/0375B4A0,
I think this is useful information and can be even included in core
code.
Thanks.
Non-HOT updates can also be compressed, if they happen to land in the same page as the old version, so I copied that code into the non-HOT update section as well.
Taking a snapshot of a running pg_xlog directory, I found 25241 uncompressed and 14179 compressed tuples, so I think this feature is getting exercised, though mostly in the non-HOT form.
Some side notes:
GNU make does not realize that pg_xlogdump depends on src/backend/access/rmgrdesc/heapdesc.c. (I don't know how or why it has that dependency, but changes did not take effect with a simple "make install") Is that a known issue? Is there someway to fix it?
Also, pg_xlogdump -p .... insists on being given a start position. I would be nice if it could just find the first file in the given directory. Any reason it can't do that, other than just that no one implemented it yet?
