Horton

Re: Should use MERGE use BulkInsertState ?

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Amit Langote <amitlangote09@gmail.com>, Japin Li <japinli@hotmail.com>, Zhihong Yu <zyu@yugabyte.com>, Simon Riggs <simon.riggs@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas.vondra@enterprisedb.com>, Daniel Westermann <dwe@dbi-services.com>, Erik Rijkers <er@xs4all.nl>, Jaime Casanova <jcasanov@systemguards.com.ec>, Andres Freund <andres@anarazel.de>
Date: 2022-05-13T16:20:43Z
Lists: pgsql-hackers 
On Wed, May 11, 2022 at 12:48 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> The point of the ring/strategy buffer is to avoid a seq scan/vacuum/COPY
> clobbering the entire buffer cache when processing a table larger than
> shared_buffers.
>
> It also makes backends doing bulk operations responsible for their own writes,
> rather than leaving other backends to clean up all their dirty buffers.

Right. It's not just about how fast individual operations go: dirtying
all of shared_buffers is faster *for you* but you've imposed a
distributed cost on everyone else on the system, which isn't great.

That said, I'm not really sure what the proper handling is in this
specific case. I guess we should try our best to have it be symmetric
with other similar cases, but questions have been raised repeatedly
about how well the ring buffer stuff actually works.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Doc fixes for MERGE statement

  2. MERGE docs adjustments

  3. Link to MVCC docs in MERGE docs

  4. Fix EXPLAIN MERGE output when no tuples are processed

  5. Make EXPLAIN MERGE output format more compact

  6. Add support for MERGE SQL command

  7. Split ExecUpdate and ExecDelete into reusable pieces

  8. Add API of sorts for transition table handling in trigger.c

  9. Represent Lists as expansible arrays, not chains of cons-cells.