Re: refactoring relation extension and BufferAlloc(), faster COPY

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: refactoring relation extension and BufferAlloc(), faster COPY
Date: 2023-02-22 09:18:57
Message-ID: 16d944e7-ede2-5d49-8688-c91174f5a51e@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 21/02/2023 21:22, Andres Freund wrote:
> On 2023-02-21 18:18:02 +0200, Heikki Linnakangas wrote:
>> Is it ever possible to call this without a relcache entry? WAL redo
>> functions do that with ReadBuffer, but they only extend a relation
>> implicitly, by replay a record for a particular block.
>
> I think we should use it for crash recovery as well, but the patch doesn't
> yet. We have some gnarly code there, see the loop using P_NEW in
> XLogReadBufferExtended(). Extending the file one-by-one is a lot more
> expensive than doing it in bulk.

Hmm, XLogReadBufferExtended() could use smgrzeroextend() to fill the
gap, and then call ExtendRelationBuffered for the target page. Or the
new ExtendRelationBufferedTo() function that you mentioned.

In the common case that you load a lot of data to a relation extending
it, and then crash, the WAL replay would still extend the relation one
page at a time, which is inefficient. Changing that would need bigger
changes, to WAL-log the relation extension as a separate WAL record, for
example. I don't think we need to solve that right now, it can be
addressed separately later.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2023-02-22 09:29:38 Re: [PATCH] Support SK_SEARCHNULL / SK_SEARCHNOTNULL for heap-only scans
Previous Message Jim Jones 2023-02-22 09:15:50 Re: [PATCH] Add pretty-printed XML output option