On Fri, Aug 2, 2024 at 4:00 PM Nathan Bossart
wrote:
> On Fri, Aug 02, 2024 at 01:33:45AM -0400, Tom Lane wrote:
> > 2. On the other end of the scale, if you've got a *boatload* of
> > functions, what does it do to pg_dump's memory requirements?
>
> Hm. I think this is sufficient reason to withd
On Wed, Jun 5, 2024 at 3:05 PM Nathan Bossart
wrote:
> For pg_lfind32(), we ended up using an overlapping approach for the
> vectorized case (see commit 7644a73). That appeared to help more than it
> harmed in the many (admittedly branch predictor friendly) tests I ran. I
> wonder if you could
On Wed, Jun 5, 2024 at 12:37 PM Nathan Bossart
wrote:
> What about collectXXX() to match similar functions in pg_dump.c (e.g.,
> collectRoleNames(), collectComments(), collectSecLabels())?
>
sgtm.
> > (2) These functions malloc() a single ntups * sizeof(struct) allocation
> and
> > then index
Thanks for the review and feedback!
On Mon, Jun 3, 2024 at 10:56 AM Nathan Bossart
wrote:
> > -/*
> > - * Send text representation of one attribute, with conversion and
> escaping
> > - */
> > #define DUMPSOFAR() \
>
> IIUC this comment was meant to describe the CopyAttributeOutText() function
On Wed, Jun 5, 2024 at 11:14 AM Nathan Bossart
wrote:
> In fact, many of the functions in this area don't actually need to
return anything, so we can trim some code and hopefully reduce confusion a
> bit. Patch attached.
>
Nice cleanup! Two minor comments:
(1) Names like `getXXX` for these f
On Mon, Jun 3, 2024 at 9:22 AM Joe Conway wrote:
> Welcome back!
>
Thanks Joe! It's been a minute :)
Neil
Inspired by David Rowley's work [1] on optimizing JSON escape processing
with SIMD, I noticed that the COPY code could potentially benefit from SIMD
instructions in a few places, eg:
(1) CopyAttributeOutCSV() has 2 byte-by-byte loops
(2) CopyAttributeOutText() has 1
(3) CopyReadLineText() has 1
(4
