|From:||Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>|
|To:||Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Patch: Write Amplification Reduction Method (WARM)|
|Views:||Raw Message | Whole Thread | Download mbox|
On Wed, Mar 22, 2017 at 3:51 AM, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>
> On Tue, Mar 21, 2017 at 8:10 PM, Robert Haas <robertmhaas(at)gmail(dot)com>
> > If the WAL writing hides the loss, then I agree that's not a big
> > concern. But if the loss is still visible even when WAL is written,
> > then I'm not so sure.
> The tests table schema was taken from earlier tests what Pavan has posted
> , hence it is UNLOGGED all I tried to stress the tests. Instead of
> updating 1 row at a time through pgbench (For which I and Pavan both did
> not see any regression), I tried to update all the rows in the single
Sorry, I did not mean to suggest that you set it up wrongly, I was just
trying to point out that the test case itself may not be very practical.
But given your recent numbers, the regression is clearly non-trivial and
something we must address.
> I have changed the settings as recommended and did a quick test as above
> in our machine by removing UNLOGGED world in create table statement.
> Patch Tested : Only 0001_interesting_attrs_v18.patch in 
> Response time recorded shows there is a much higher increase in response
> time from 10% to 25% after the patch.
Thanks for repeating the tests. They are very useful. It might make sense
to reverse the order or do 6 tests each and alternate between patched and
unpatched master just to get rid of any other anomaly.
BTW may I request another test with the attached patch? In this patch, we
check if the PageIsFull() even before deciding which attributes to check
for modification. If the page is already full, there is hardly any chance
of doing a HOT update (there could be a corner case where the new tuple is
smaller than the tuple used in previous UPDATE and we have just enough
space to do HOT update this time, but I can think that's too narrow).
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
|Next Message||Tom Lane||2017-03-22 03:34:49||Re: Allow pg_dumpall to work without pg_authid|
|Previous Message||Amit Kapila||2017-03-22 03:11:48||Re: segfault in hot standby for hash indexes|