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

From: Jim Nasby <nasbyj(at)amazon(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: <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-21 22:49:37
Message-ID: 2f2b4022-d39d-5e32-b738-1672a593ba83@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 can confirm 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2023-02-21 23:03:52 Auth extensions, with an LDAP/SCRAM example [was: Proposal: Support custom authentication methods using hooks]
Previous Message Jacob Champion 2023-02-21 22:24:12 Re: [PoC] Federated Authn/z with OAUTHBEARER