Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tBjq2-005n5o-EN for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Nov 2024 00:05:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tBjpz-007D1j-Hp for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Nov 2024 00:05:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tBjpz-007D1b-8W for pgsql-hackers@lists.postgresql.org; Fri, 15 Nov 2024 00:05:23 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tBjpw-001ufC-IL for pgsql-hackers@postgresql.org; Fri, 15 Nov 2024 00:05:22 +0000 Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2ff589728e4so13138571fa.1 for ; Thu, 14 Nov 2024 16:05:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731629118; x=1732233918; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jJIZrkrESPMZOOnP/K5p4cRkFXw3FTQ5aC3TIJhC50M=; b=CohHFipn1WzEHy0onhCPiuW6AxgxbDWy8OdXfV3EJkufMK0vkmX2auO9wBEsXy00lo p1znDc6NDvn1+QZHy51pYOnTMHODQYoCtMn8tzbCXojunv5Hh09MsOFcuTTYNLWPJL4G wrE35aHhdD7gbDEPBXEks5mJDIigMSVuU/R0hjBTQ0oohthtmfY8l1/XytFOdDVr6C3z KB1B0kQPMgtmqPv91r3j9UB+WkjkEUS1QtTIRw2tPjUgSTnV0BdFJFHKeYPj56U5xh9O TQ4GyUt2D3vr+mEOfjjc6ZUN79CRqO9n/U8NjuHEhHAy99x3zewDeB/W3SLuwC7o2WB5 QxvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731629118; x=1732233918; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jJIZrkrESPMZOOnP/K5p4cRkFXw3FTQ5aC3TIJhC50M=; b=bxNvFVat2Fca/MObfksVBgjqu8nFI9WC1MZLcC/Or2dwnlCMhF5iG/FkoHyEkbz0Er XaoRPDyo9iyy+81xFvLgyN/p1q1d4KgbLqQDqO5F+vavJ52ok2ErLCs1gK/7JgNM8+uJ pGwNgB71666Wgl+k7g6MnnjYIUZjk4oU0CL93DK3gNSWMneDdYXb7ArvpMXPIeYfTLla TTcgVgEIlg/dBgDVS/VacwZgrasYL+R5/vptxzyNS9r/Jkg0Q6qLwnsuVwVmQDjtnamF eymxxzAiFCmAg0yBQs+FTzNoXkoYICYhfJHY8jS5MDXJIKQJsxeV+sgly5gD8M3G7+lk 2ISA== X-Forwarded-Encrypted: i=1; AJvYcCW4lF1rXGTse3IYN/rfmZdhBgf7vHR33d5LoU6p4UXg1d1mOf+wP84kcPmR4Cj+UFghjzgIqiXGgIY/C2UL@postgresql.org X-Gm-Message-State: AOJu0Yzi73IRvMgkL4ZH0GO931ne6ecr7z5XlKANZjfz341vUhQmuQrv O28v+cEassCNBeoa6bwBuV/Ovl0XtlD/XYEELJwP7dZUBpt4Z5Wb2tXRO10YLjyHABWmMnThblT 8X+82xd7j6pPN+MP+xWkHa5830KU= X-Google-Smtp-Source: AGHT+IHjmK/SgNenGJe+fs3EeCCLRStfGmM7F8U7UBHN4IPK9hXzn4ybgnSVdfa/7qLpteFLTxgM3ClBfCf+z9Z8cwc= X-Received: by 2002:a05:651c:158c:b0:2ff:5ec5:15fa with SMTP id 38308e7fff4ca-2ff60725bf0mr2796981fa.19.1731629118284; Thu, 14 Nov 2024 16:05:18 -0800 (PST) MIME-Version: 1.0 References: <20241105.174328.1705956947135248653.kou@clear-code.com> <20241114.161948.1677325020727842666.kou@clear-code.com> In-Reply-To: <20241114.161948.1677325020727842666.kou@clear-code.com> From: Masahiko Sawada Date: Thu, 14 Nov 2024 16:04:41 -0800 Message-ID: Subject: Re: Make COPY format extendable: Extract COPY TO format implementations To: Sutou Kouhei Cc: michael@paquier.xyz, pgsql-hackers@postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Nov 13, 2024 at 11:19=E2=80=AFPM Sutou Kouhei = wrote: > > Hi, > > In <20241105.174328.1705956947135248653.kou@clear-code.com> > "Re: Make COPY format extendable: Extract COPY TO format implementation= s" on Tue, 05 Nov 2024 17:43:28 +0900 (JST), > Sutou Kouhei wrote: > > >> I've further investigated the performance regression, and found out it > >> might be relevant that the compiler doesn't inline the > >> CopyFromTextLikeOneRow() function. It might be worth testing with > >> pg_attribute_always_inline instead of 'inline' as below: > > > > Wow! Good catch! > > > > I've rebased on the current master and updated the v20 and > > v21 patch sets with "pg_attribute_always_inline" not > > "inline". > > > > The v22 patch set is for the v20 patch set. > > (TO/FROM changes are in one commit.) > > > > The v23 patch set is for the v21 patch set. > > (TO/FROM changes are separated for easy to merge only FROM > > or TO part.) > > I've run benchmark on my machine that has "Intel(R) Core(TM) > i7-3770 CPU @ 3.40GHz". > > Summary: > * "pg_attribute_always_inline" is effective for the "COPY > FROM" part > * "pg_attribute_always_inline" may not be needed for the > "COPY TO" part > > > v20-result.pdf: This is the same result PDF attached in > https://www.postgresql.org/message-id/20241008.173918.995935870630354246.= kou%40clear-code.com > . This is the base line for "pg_attribute_always_inline" > change. > > v22-result.pdf: This is a new result PDF for the v22 patch > set. > > COPY FROM: > > 0001: The v22 patch set is slower than HEAD. This just > introduces "routine" abstraction. It increases overhead. So > this is expected. > > 0002-0005: The v22 patch set is faster than HEAD for all > cases. The v20 patch set is slower than HEAD for smaller > data. This shows that "pg_attribute_always_inline" for the > "COPY FROM" part is effective on my machine too. > > > COPY TO: > > 0001: The v22 patch set is slower than HEAD. This is > as expected for the same reason as COPY FROM. > > 0002-0004: The v22 patch set is slower than HEAD. (The v20 > patch set is faster than HEAD.) This is not expected. > > 0005: The v22 patch set is faster than HEAD. This is > expected. But 0005 just exports some functions. It doesn't > change existing logic. So it's strange... > > This shows "pg_attribute_always_inline" is needless for the > "COPY TO" part. > > > I also tried the v24 patch set: > * The "COPY FROM" part is same as the v22 patch set > ("pg_attribute_always_inline" is used.) > * The "COPY TO" part is same as the v20 patch set > ("pg_attribute_always_inline" is NOT used.) > > > (I think that the v24 patch set isn't useful for others. So > I don't share it here. If you're interested in it, I'll > share it here.) > > v24-result.pdf: > > COPY FROM: The same trend as the v22 patch set result. It's > expected because the "COPY FROM" part is the same as the v22 > patch set. > > COPY TO: The v24 patch set is faster than the v22 patch set > but the v24 patch set isn't same trend as the v20 patch > set. This is not expected because the "COPY TO" part is the > same as the v20 patch set. > > > Anyway, the 0005 "COPY TO" parts are always faster than > HEAD. So we can use either "pg_attribute_always_inline" or > "inline". > > > Summary: > * "pg_attribute_always_inline" is effective for the "COPY > FROM" part > * "pg_attribute_always_inline" may not be needed for the > "COPY TO" part > > > Can we proceed this proposal with these results? Or should > we wait for more benchmark results? Thank you for sharing the benchmark test results! I think these results are good for us to proceed. I'll closely look at COPY TO results and review v22 patch sets. Regards, --=20 Masahiko Sawada Amazon Web Services: https://aws.amazon.com