MIME-Version: 1.0
References: 
 <CADzfLwW9QczZW-E=McxcjUv0e5VMDctQNETbgao0K-SimVhFPA@mail.gmail.com>
 <202505181556.3n6oiowvntyr@alvherre.pgsql>
 <CADzfLwXKtriMnfCNVGNH2ahwXaByjo-QOMWiDTU-9WZqh+zQ5g@mail.gmail.com>
 <CADzfLwW5bDWSxjHK7mqX8Lewki3+5FBydBC+nVcxg4xMGKscyw@mail.gmail.com>
In-Reply-To: 
 <CADzfLwW5bDWSxjHK7mqX8Lewki3+5FBydBC+nVcxg4xMGKscyw@mail.gmail.com>
From: Sergey Sargsyan <sergey.sargsyan.2001@gmail.com>
Date: Mon, 16 Jun 2025 19:17:33 +0300
Message-ID: 
 <CAMAof6-4xaV3QE2ErYJaJhu6qjFn99sWyo_HQeBhHikZM3GexA@mail.gmail.com>
Subject: Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Cc: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>,
	Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
 Andrey Borodin <amborodin86@gmail.com>,
	Melanie Plageman <melanieplageman@gmail.com>,
	Matthias van de Meent <boekewurm+postgres@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005b512c0637b2bc78"
Archived-At: 
 <https://www.postgresql.org/message-id/CAMAof6-4xaV3QE2ErYJaJhu6qjFn99sWyo_HQeBhHikZM3GexA%40mail.gmail.com>
Precedence: bulk

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

Hey Mihail,

I've started looking at the patches today, mostly the STIR part. Seems
solid, but I've got a question about validation. Why are we still grabbing
tids from the main index and sorting them?

I think it's to avoid duplicate errors when adding tuples from STIP to the
main index, but couldn't we just suppress that error during validation and
skip the new tuple insertion if it already exists?

The main index may get huge after building, and iterating over it in a
single thread and then sorting tids can be time consuming.

At least I guess one can skip it when STIP is empty. But, I think we could
skip it altogether by figuring out what to do with duplicates, making
concurrent and non-concurrent index creation almost identical in speed
(only locking and atomicity would differ).

p.s. I noticed that `stip.c` has a lot of functions that don't follow the
Postgres coding style of return type on separate line.

On Mon, Jun 16, 2025, 6:41=E2=80=AFPM Mihail Nikalayeu <mihailnikalayeu@gma=
il.com>
wrote:

> Hello, everyone!
>
> Rebased, patch structure and comments available here [0]. Quick
> introduction poster - here [1].
>
> Best regards,
> Mikhail.
>
> [0]:
> https://www.postgresql.org/message-id/flat/CADzfLwVOcZ9mg8gOG%2BKXWurt%3D=
MHRcqNv3XSECYoXyM3ENrxyfQ%40mail.gmail.com#52c97e004b8f628473124c05e3bf2da1
> [1]:
> https://www.postgresql.org/message-id/attachment/176651/STIR-poster.pdf
>

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

<div dir=3D"auto">Hey Mihail,<div dir=3D"auto"><br></div><div dir=3D"auto">=
I&#39;ve started looking at the patches today, mostly the STIR part. Seems =
solid, but I&#39;ve got a question about validation. Why are we still grabb=
ing tids from the main index and sorting them?</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">I think it&#39;s to avoid duplicate errors when addi=
ng tuples from STIP to the main index, but couldn&#39;t we just suppress th=
at error during validation and skip the new tuple insertion if it already e=
xists?</div><div dir=3D"auto"><br></div><div dir=3D"auto">The main index ma=
y get huge after building, and iterating over it in a single thread and the=
n sorting tids can be time consuming.</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">At least I guess one can skip it when STIP is empty. But, I t=
hink we could skip it altogether by figuring out what to do with duplicates=
, making concurrent and non-concurrent index creation almost identical in s=
peed (only locking and atomicity would differ).</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">p.s. I noticed that `stip.c` has a lot of functions=
 that don&#39;t follow the Postgres coding style of return type on separate=
 line.</div></div><br><div class=3D"gmail_quote gmail_quote_container"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 16, 2025, 6:41=E2=80=AFPM Mih=
ail Nikalayeu &lt;<a href=3D"mailto:mihailnikalayeu@gmail.com">mihailnikala=
yeu@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,=
 everyone!<br>
<br>
Rebased, patch structure and comments available here [0]. Quick<br>
introduction poster - here [1].<br>
<br>
Best regards,<br>
Mikhail.<br>
<br>
[0]: <a href=3D"https://www.postgresql.org/message-id/flat/CADzfLwVOcZ9mg8g=
OG%2BKXWurt%3DMHRcqNv3XSECYoXyM3ENrxyfQ%40mail.gmail.com#52c97e004b8f628473=
124c05e3bf2da1" rel=3D"noreferrer noreferrer" target=3D"_blank">https://www=
.postgresql.org/message-id/flat/CADzfLwVOcZ9mg8gOG%2BKXWurt%3DMHRcqNv3XSECY=
oXyM3ENrxyfQ%40mail.gmail.com#52c97e004b8f628473124c05e3bf2da1</a><br>
[1]: <a href=3D"https://www.postgresql.org/message-id/attachment/176651/STI=
R-poster.pdf" rel=3D"noreferrer noreferrer" target=3D"_blank">https://www.p=
ostgresql.org/message-id/attachment/176651/STIR-poster.pdf</a><br>
</blockquote></div>

--0000000000005b512c0637b2bc78--