RE: Speed up transaction completion faster after many relations areaccessed in a transaction - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Speed up transaction completion faster after many relations areaccessed in a transaction
Date
Msg-id 0A3221C70F24FB45833433255569204D1FC8396B@G01JPEXMBYT05
Whole thread Raw
In response to Re: Speed up transaction completion faster after many relations areaccessed in a transaction  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Speed up transaction completion faster after many relations areaccessed in a transaction
List pgsql-hackers
From: David Rowley [mailto:david.rowley@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_receivewal documentation
Next
From: "Matsumura, Ryo"
Date:
Subject: [Patch] PQconnectPoll() is blocked if target_session_attrs isread-write