|From:||"Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>|
|To:||'David Rowley' <david(dot)rowley(at)2ndquadrant(dot)com>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, "Imai, Yoshikazu" <imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||RE: Speed up transaction completion faster after many relations are accessed in a transaction|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
From: David Rowley [mailto:david(dot)rowley(at)2ndquadrant(dot)com]
> I personally don't think that's true. The only way you'll notice the
> LockReleaseAll() overhead is to execute very fast queries with a
> bloated lock table. It's pretty hard to notice that a single 0.1ms
> query is slow. You'll need to execute thousands of them before you'll
> be able to measure it, and once you've done that, the lock shrink code
> will have run and the query will be performing optimally again.
Maybe so. Will the difference be noticeable between plan_cache_mode=auto (default) and plan_cache_mode=custom?
> I voice my concerns with v5 and I wasn't really willing to push it
> with a known performance regression of 7% in a fairly valid case. v6
> does not suffer from that.
You're right. We may have to consider the unpredictability to users by this hidden behavior as a compromise for higher throughput.
> > Where else does the extra overhead come from?
> hash_get_num_entries(LockMethodLocalHash) == 0 &&
> + hash_get_max_bucket(LockMethodLocalHash) >
> + LOCKMETHODLOCALHASH_SHRINK_THRESHOLD)
> that's executed every time, not every 1000 times.
I see. Thanks.
|Next Message||Matsumura, Ryo||2019-07-22 02:28:22||[Patch] PQconnectPoll() is blocked if target_session_attrs is read-write|
|Previous Message||Michael Paquier||2019-07-22 01:48:51||Re: pg_receivewal documentation|