RE: Speed up transaction completion faster after many relations areaccessed in a transaction
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: Speed up transaction completion faster after many relations areaccessed in a transaction |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FC8396B@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: Speed up transaction completion faster after many relations areaccessed in a transaction (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: Speed up transaction completion faster after many relations areaccessed in a transaction
|
Список | 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 по дате отправления: