Re: Speed up transaction completion faster after many relations are accessed in a transaction
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: David Rowley <david.rowley@2ndquadrant.com>,
"Tsunakawa,
Takayuki" <tsunakawa.takay@jp.fujitsu.com>,
"pgsql-hackers@lists.postgresql.org"
<pgsql-hackers@lists.postgresql.org>
Date: 2019-02-19T00:01:06Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > Isn't a large portion of benefits in this patch going to be mooted by > the locking improvements discussed in the other threads? I.e. there's > hopefully not going to be a ton of cases with low overhead where we > acquire a lot of locks and release them very soon after. Sure, for DDL > etc we will, but I can't see this mattering from a performance POV? Mmm ... AIUI, the patches currently proposed can only help for what David called "point lookup" queries. There are still going to be queries that scan a large proportion of a partition tree, so if you've got tons of partitions, you'll be concerned about this sort of thing. > I'm not against doing something like Tom proposes, but heuristics with > magic constants like this tend to age purely / are hard to tune well > across systems. I didn't say it had to be a constant ... regards, tom lane
Commits
-
Reorder LOCALLOCK structure members to compact the size
- 28988a84cf19 12.0 landed
-
Be more careful to not lose sync in the FE/BE protocol.
- 2b3a8b20c2da 9.5.0 cited