Re: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Dilip Kumar <dilipbalaut@gmail.com>, Luc Vlaming <luc@swarm64.com>, Justin Pryzby <pryzby@telsasoft.com>, Michael Paquier <michael@paquier.xyz>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Alexander Korotkov <aekorotkov@gmail.com>
Date: 2024-05-15T22:03:19Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
libpq: Fix some issues in TAP tests for service files
- 2c7bd2ba507e 18.0 cited
-
Multiple revisions to the GROUP BY reordering tests
- 874d817baa16 17.0 cited
-
Explore alternative orderings of group-by pathkeys during optimization.
- 0452b461bc40 17.0 cited
Hi, On 2024-05-15 11:14:14 +0200, Alvaro Herrera wrote: > On 2024-May-15, Bharath Rupireddy wrote: > > > It looks like with the use of the new multi insert table access method > > (TAM) for COPY (v20-0005), pgbench regressed about 35% [1]. > > Where does this acronym "TAM" comes from for "table access method"? I > find it thoroughly horrible and wish we didn't use it. What's wrong > with using "table AM"? It's not that much longer, much clearer and > reuses our well-established acronym AM. Strongly agreed. I don't know why I dislike TAM so much though. Greetings, Andres Freund