| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(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-02-18 23:52:08 |
| Message-ID: | CAKJS1f8aGgg0T35-kjBeBGNGosnkhw6_gdWzf28p0KVGV5XTtA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 19 Feb 2019 at 12:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> My own thought about how to improve this situation was just to destroy
> and recreate LockMethodLocalHash at transaction end (or start)
> if its size exceeded $some-value. Leaving it permanently bloated seems
> like possibly a bad idea, even if we get rid of all the hash_seq_searches
> on it.
That seems like a good idea. Although, it would be good to know that
it didn't add too much overhead dropping and recreating the table when
every transaction happened to obtain more locks than $some-value. If
it did, then maybe we could track the average locks per of recent
transactions and just ditch the table after the locks are released if
the locks held by the last transaction exceeded the average *
1.something. No need to go near shared memory to do that.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | James Sewell | 2019-02-18 23:52:54 | Re: Reaping Temp tables to avoid XID wraparound |
| Previous Message | Tom Lane | 2019-02-18 23:50:34 | Re: Delay locking partitions during query execution |