| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, "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-04-07 16:09:40 |
| Message-ID: | 21531.1554653380@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Rowley <david(dot)rowley(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2019-04-07 16:09:57 | Re: query logging of prepared statements |
| Previous Message | Alvaro Herrera | 2019-04-07 16:07:50 | Re: ToDo: show size of partitioned table |