| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Reviewing freeze map code |
| Date: | 2016-06-29 17:00:50 |
| Message-ID: | 20160629170050.zpvcmaz3ni2y75d7@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2016-06-29 19:04:31 +0530, Amit Kapila wrote:
> There is nothing in this record which recorded the information about
> visibility clear flag.
I think we can actually defer the clearing to the lock release? A tuple
being locked doesn't require the vm being cleared.
> I think in this approach, it is important to measure the performance
> of update, may be you can use simple-update option of pgbench for
> various workloads. Try it with different fill factors (-F fillfactor
> option in pgbench).
Probably not sufficient, also needs toast activity, to show the really
bad case of many lock releases.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-06-29 17:26:02 | Re: fixing consider_parallel for upper planner rels |
| Previous Message | Robert Haas | 2016-06-29 16:58:47 | Re: A couple of cosmetic changes around shared memory code |