On Thu, Jan 5, 2017 at 6:15 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>
> Your test and results look good, what kind of m/c you have used to
> test this. Let me see if I or one of my colleague can do this and
> similar test on some high-end m/c.
As discussed with Amit, I have tried to run the same tests with below
modification,
1. Increased the total rows to 10milion.
2. Set fsync off;
3. Changed tests as below. Updated all rows at a time.
VACUUM FULL;
BEGIN;
UPDATE testtab SET col2 = md5(random()::text);
ROLLBACK;
I have run these tests on IBM power2 which have sufficient ram. I have
set shared_buffer=32GB.
My results show after this patch there is a slight increase in
response time (psql \timing was used) for the above update statement.
Which is around 5 to 10% delay.
Runs Response time in ms for update base. Response
Time in ms for update new patch. %INC
1 158863.501
167443.767
5.4010304104
2 151061.793
168908.536
11.8142004312
3 153750.577
164071.994
6.7130915548
4 153639.165
168364.225
9.5841838245
5 149607.139
166498.44
11.2904378179
Under the same condition running original tests, that is, updating
rows which satisfy a condition col1 = :value1. I did not see any
regression.
--
Thanks and Regards
Mithun C Y
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
