Re: refactoring relation extension and BufferAlloc(), faster COPY - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: refactoring relation extension and BufferAlloc(), faster COPY
Date
Msg-id 2f2b4022-d39d-5e32-b738-1672a593ba83@amazon.com
Whole thread Raw
In response to Re: refactoring relation extension and BufferAlloc(), faster COPY  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2/21/23 3:12 PM, Andres Freund wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you
canconfirm the sender and know the content is safe.
 
>
>
>
> Hi,
>
> On 2023-02-21 15:00:15 -0600, Jim Nasby wrote:
>> Some food for thought: I think it's also completely fine to extend any
>> relation over a certain size by multiple blocks, regardless of concurrency.
>> E.g. 10 extra blocks on an 80MB relation is 0.1%. I don't have a good feel
>> for what algorithm would make sense here; maybe something along the lines of
>> extend = max(relpages / 2048, 128); if extend < 8 extend = 1; (presumably
>> extending by just a couple extra pages doesn't help much without
>> concurrency).
> I previously implemented just that. It's not easy to get right. You can easily
> end up with several backends each extending the relation by quite a bit, at
> the same time (or you re-introduce contention). Which can end up with a
> relation being larger by a bunch if data loading stops at some point.
>
> We might want that as well at some point, but the approach implemented in the
> patchset is precise and thus always a win, and thus should be the baseline.
Yeah, what I was suggesting would only make sense when there *wasn't* 
contention.



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Next
From: Jacob Champion
Date:
Subject: Auth extensions, with an LDAP/SCRAM example [was: Proposal: Support custom authentication methods using hooks]