Re: Speed up transaction completion faster after many relations are accessed in a transaction
От | Tom Lane |
---|---|
Тема | Re: Speed up transaction completion faster after many relations are accessed in a transaction |
Дата | |
Msg-id | 21531.1554653380@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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
Re: Speed up transaction completion faster after many relations areaccessed in a transaction |
Список | pgsql-hackers |
David Rowley <david.rowley@2ndquadrant.com> writes: > Okay. Here's another version with all the average locks code removed > that only recreates the table when it's completely empty. Um ... I don't see where you're destroying the old hash? Also, I entirely dislike wiring in assumptions about hash_seq_search's private state structure here. I think it's worth having an explicit entry point in dynahash.c to get the current number of buckets. Also, I would not define "significantly bloated" as "the table has grown at all". I think the threshold ought to be at least ~100 buckets, if we're starting at 16. Probably we ought to try to gather some evidence to inform the choice of cutoff here. Maybe instrument the regression tests to see how big the table typically gets? regards, tom lane
В списке pgsql-hackers по дате отправления: