Re: Speed up transaction completion faster after many relations are accessed in a transaction
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
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:06:26Z
Lists: pgsql-hackers
Hi, On 2019-02-18 19:01:06 -0500, Tom Lane wrote: > 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. Agreed - but it seems not unlikely that for those the rest of the planner / executor overhead will entirely swamp any improvement we could make here. If I understand correctly the benchmarks here were made with "point" update and select queries, although the reference in the first post in this thread is a bit vague. > > 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 ... Do you have good idea? Greetings, Andres Freund
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