MIME-Version: 1.0
References: <CAFjYY++22tmGDSac_YPA_NLJ4-cEJo7kS3SxXFHf7ZFTnwO-QA@mail.gmail.com>
 <CAFjYY+J7ZcJAoE+K4AoyuiS_N6w8vVCQ6HQ72mPB=i4C+QbAeQ@mail.gmail.com>
 <CAFjYY+KhiuzocMdgEr8wQtCkSaec=Mu_YiLE6N3JfYtQ-Xv=ug@mail.gmail.com>
 <CAFjYY++YjtunZcFt7MFBWwseP_=GS11=V36_xig07enHA0eRjA@mail.gmail.com>
 <CAPpHfdvD-oqh=qvtkD3qWqZrfxt0+PtdwyRYC+faQd-rr+V0mg@mail.gmail.com>
 <7bcc0420-d457-4af5-a459-a4e5d929a665@vondra.me> <CAFjYY+Lhw2tvsiC8_Dbx+K9dMaK=myT5Cck2=8FgLUW5f9Hp-A@mail.gmail.com>
 <udbqvyuxlxk4a64uomo5xmgloemk7jrbeeluhvxbdqxcdv2pt5@who34o73ttmo>
 <CAFjYY+LcBCPe9cboef1GteAPKEiqyTTww7NGxa==roc6QXSOxA@mail.gmail.com>
 <CAFjYY+LJ5_j82PrSxm2RjM0OjwfN9smJ1VKKMOka-25Jg-0ofg@mail.gmail.com>
 <7gbzkoxrpqvj2sgxof4pqirz7pf6wb5vizak3mxrz2zpvrf3pa@lvnwdsy3em56>
 <CAFjYY+LH=MbMpGiYfMtPsANDBAqiDC66hD3tBs_JeVcBYVcmHA@mail.gmail.com>
 <CAFjYY+Jfsy1r4ZP4+RyHZeWE7JyT4LSdVFvA9ck04LFkKd1ebw@mail.gmail.com>
 <CAFjYY+K=s8gL=3SN8puwjSm5ZvUXumsdeB-Z2rwLP5OQNtEF+Q@mail.gmail.com>
 <CAEvyyThUp+Cyv8Se6dxpJvP7w=u1670Xd4k6zeXGVSac7UOm_A@mail.gmail.com>
 <CAFjYY+KjoNLYGFeM4z=DOgG1uDwXD1Z6zyurgz1d9Y-96X=9GA@mail.gmail.com>
 <CAFjYY+JDSpOQwYAfTQQ43=BA=d32XfcAdaPVJgHheV9fQBbLWg@mail.gmail.com> <CAN4CZFPmAwOvR8r1gtv=r+4akArZJyjna_Nxgkn_eTcsRs4XPA@mail.gmail.com>
In-Reply-To: <CAN4CZFPmAwOvR8r1gtv=r+4akArZJyjna_Nxgkn_eTcsRs4XPA@mail.gmail.com>
From: lakshmi <lakshmigcdac@gmail.com>
Date: Tue, 20 Jan 2026 16:21:14 +0530
Message-ID: <CAEvyyTjiUhEUX5jxJkHHncnKSuCmf=MitZLtDt+Z6WsNNo0vCQ@mail.gmail.com>
Subject: Re: Proposal: Adding compression of temporary files
To: Filip Janus <fjanus@redhat.com>
Cc: Tomas Vondra <tv@fuzzy.cz>, pgsql-hackers@postgresql.org, zsolt.parragi@percona.com
Content-Type: multipart/alternative; boundary="000000000000644d0e0648cf8ed6"
Archived-At: <https://www.postgresql.org/message-id/CAEvyyTjiUhEUX5jxJkHHncnKSuCmf%3DMitZLtDt%2BZ6WsNNo0vCQ%40mail.gmail.com>
Precedence: bulk

--000000000000644d0e0648cf8ed6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Filip,

I tested both patches on current master using git am -3 .They apply
cleanly,build fine,and the temp_file _compression GUC works as expected.
Query results are unchanged.

For hash join spill test,temp files were created as expected,but the logged
size were same for no,lz4,and pglz,which seems consistent with fixed-size
fileset chunking.It might be helpful to briefly note this in the
documentation to avoid confusion.

Thanks for working on this .
best regards,
lakshmi

On Tue, Jan 20, 2026 at 4:10=E2=80=AFAM Zsolt Parragi <zsolt.parragi@percon=
a.com>
wrote:

> Hello!
>
> I tried to review the code. It compiled, the test suite passed.
>
> I noticed two typos:
>
> buffile.c:77 - "Disaled"
> buffile.c:133 - "mathods"
>
> And a few other small findings:
>
> buffile.h:35 and buffile.c:63 - same constants defined first as an
> Enum and then as #defines - code builds properly without the defines.
>
> buffile.c:121 - compress_tempfile is defined, set to false at :167,
> but never used otherwise
>
> guc_tables.c:470 - the comment says that pglz isn't supported yet, but
> we have a value for it, and I see support for it in the code
>
> buffile.c:659: (and at other places) if USE_LZ4 is undefined, the
> codepath doesn't do anything. I think these ifdefs should follow how
> other compression code works, such as wal compression where there's an
> #else path with elog(ERROR, ...)
> Similarly, maybe there should be an explicit TEMP_NONE_COMPRESSION
> branch that does nothing, and the default branch should be an error?
>
> buffile.c:265: If seek isn't supported/limited, shouldn't there be at
> least an assertion about it in BufFileSeek? And tell isn't mentioned,
> but it seems to me that tell also doesn't work properly.
>

--000000000000644d0e0648cf8ed6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Filip,<br><br>I tested both patches on current master u=
sing git am -3 .They apply cleanly,build fine,and the temp_file _compressio=
n GUC works as expected.<br>Query results are unchanged.<br><br>For hash jo=
in spill test,temp files were created as expected,but the logged size were =
same for no,lz4,and pglz,which seems consistent with fixed-size fileset chu=
nking.It might be helpful to briefly note this in the documentation to avoi=
d confusion.<br><br>Thanks for working on this .<br>best regards,<br>lakshm=
i</div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr=
" class=3D"gmail_attr">On Tue, Jan 20, 2026 at 4:10=E2=80=AFAM Zsolt Parrag=
i &lt;<a href=3D"mailto:zsolt.parragi@percona.com">zsolt.parragi@percona.co=
m</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Hello!<br>
<br>
I tried to review the code. It compiled, the test suite passed.<br>
<br>
I noticed two typos:<br>
<br>
buffile.c:77 - &quot;Disaled&quot;<br>
buffile.c:133 - &quot;mathods&quot;<br>
<br>
And a few other small findings:<br>
<br>
buffile.h:35 and buffile.c:63 - same constants defined first as an<br>
Enum and then as #defines - code builds properly without the defines.<br>
<br>
buffile.c:121 - compress_tempfile is defined, set to false at :167,<br>
but never used otherwise<br>
<br>
guc_tables.c:470 - the comment says that pglz isn&#39;t supported yet, but<=
br>
we have a value for it, and I see support for it in the code<br>
<br>
buffile.c:659: (and at other places) if USE_LZ4 is undefined, the<br>
codepath doesn&#39;t do anything. I think these ifdefs should follow how<br=
>
other compression code works, such as wal compression where there&#39;s an<=
br>
#else path with elog(ERROR, ...)<br>
Similarly, maybe there should be an explicit TEMP_NONE_COMPRESSION<br>
branch that does nothing, and the default branch should be an error?<br>
<br>
buffile.c:265: If seek isn&#39;t supported/limited, shouldn&#39;t there be =
at<br>
least an assertion about it in BufFileSeek? And tell isn&#39;t mentioned,<b=
r>
but it seems to me that tell also doesn&#39;t work properly.<br>
</blockquote></div>

--000000000000644d0e0648cf8ed6--