RE: Speed up transaction completion faster after many relations are accessed in a transaction

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
Date: 2019-07-22 02:21:16
Message-ID: 0A3221C70F24FB45833433255569204D1FC8396B@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Regards
Takayuki Tsunakawa

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
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