MIME-Version: 1.0
References: <CAKU4AWoqAVya6PBhn+BCbFaBMt3z-2=i5fKO3bW=6HPhbid2Dw@mail.gmail.com>
 <CACJufxHASOEpngQ8V2tbXgs4VZC3ETrVbS=uk0KC_B_J1j7ejQ@mail.gmail.com>
 <CAKU4AWrap1zpYqunJwWTN=CdP7E8e0U4mYmwn7hvTW3ERuENVg@mail.gmail.com>
 <CAFj8pRD-R-GsGCjeYApbhZoiW8TV6zACaYStMBMM0=--+WgN_A@mail.gmail.com>
 <CAKU4AWpDdFXAD+dMC1HeErXSKBUUBRGWkf=dAcX3wZgBNsWM=g@mail.gmail.com>
 <CAFj8pRAO3oEiBaJJ9=HZp6CoP2ffbwSgrKkLKjPfYZwx9wOOuQ@mail.gmail.com>
 <CAKU4AWoCHpKAVuQeOrk44cVPy_dVxn1aHrMUvHy5Ag-daFCSsQ@mail.gmail.com>
 <CAFj8pRD4cdUmK0RG4oN5B2KRSeDhwfMYaL=XpfEu4iaLeZ_Kow@mail.gmail.com>
 <CAKU4AWp8ab61e96v57OaB-Gm1bMfBNVLVy+s17U6_Ne3veB84g@mail.gmail.com>
 <3507485.1691090027@sss.pgh.pa.us> <CAKU4AWp+KLes8g=BWLqZfDmW9+=ZY0UC4G0i3qVcYEviK_dDTA@mail.gmail.com>
 <900892914fdc3f477b101d699efb40e0@anastigmatix.net> <903341.1692022214@sss.pgh.pa.us>
 <CAKU4AWrBY9GHj9oZbvhiOG1BgiWyZC8FGPAET-CfRKDhYyv1HQ@mail.gmail.com>
 <CAKU4AWrGM5bK7wi4Y8bTYhKgh=A1fW=X00eC_jfk6_JXyaEURQ@mail.gmail.com>
 <CAFj8pRC+4pvSuibB2xcNKJ=6PSF=TAcOtRNpdLPBXZjijFg7ag@mail.gmail.com>
 <CAKU4AWoVBY99ECX5C8XtrfaXCs2SonJjSGFOQrFUPxtRo4THPg@mail.gmail.com> <CAFj8pRBWchhjivpUzQmBeAyfq0VF4bfBKw2f0ORoaPwVUWm2HA@mail.gmail.com>
In-Reply-To: <CAFj8pRBWchhjivpUzQmBeAyfq0VF4bfBKw2f0ORoaPwVUWm2HA@mail.gmail.com>
From: Andy Fan <zhihui.fan1213@gmail.com>
Date: Tue, 15 Aug 2023 15:05:26 +0800
Message-ID: <CAKU4AWo+i-8rGH6iAF9vkh_f022PppU5GnwNn3-FeRVMBEgK4w@mail.gmail.com>
Subject: Re: Extract numeric filed in JSONB more effectively
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Chapman Flack <chap@anastigmatix.net>, 
	jian he <jian.universality@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000005936420602f0ce9b"
Archived-At: <https://www.postgresql.org/message-id/CAKU4AWo%2Bi-8rGH6iAF9vkh_f022PppU5GnwNn3-FeRVMBEgK4w%40mail.gmail.com>
Precedence: bulk

--0000000000005936420602f0ce9b
Content-Type: text/plain; charset="UTF-8"

>
> a) effectiveness. The ending performance should be similar like your
> current patch, but without necessity to use planner support API.
>

So the cost is we need to create a new & different framework.

>
>
b) because you can write only var := j->'f', and plpgsql forces cast
> function execution, but not via planner.
>

var a := 1 needs going with planner,  IIUC,  same with j->'f'.

c) nothing else. It should not to require to modify cast function
> definitions
>

If you look at how the planner support function works,  that is
pretty simple,  just modify the prosupport attribute. I'm not sure
this should be called an issue or avoiding it can be described
as a benefit.

I don't think the current case is as bad as the other ones like
users needing to modify their queries or type-safety system
being broken. So personally I'm not willing to creating some
thing new & heavy. However I'm open to see what others say.

-- 
Best Regards
Andy Fan

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div><br></div><div>a) effectiveness. The ending performan=
ce should be similar like your current patch, but without necessity to use =
planner support API.</div></div></div></blockquote><div>=C2=A0</div><div>So=
 the cost is we need to create a new &amp; different framework.=C2=A0=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_quote"><div>=C2=A0<br></div></div></div></blockquote><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div></div><div>b) because you can write only var :=3D j-&=
gt;&#39;f&#39;, and plpgsql forces cast function execution, but not via pla=
nner.</div></div></div></blockquote><div>=C2=A0</div><div>var a :=3D 1 need=
s going with planner,=C2=A0 IIUC,=C2=A0 same with j-&gt;&#39;f&#39;.=C2=A0=
=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></div><div>c) nothing el=
se. It should not to require to modify cast function definitions <br></div>=
<div></div></div></div></blockquote><div>=C2=A0</div><div>If you look at ho=
w the planner support function works,=C2=A0 that is</div><div>pretty simple=
,=C2=A0 just modify the prosupport attribute. I&#39;m not sure</div><div>th=
is should be called an issue or avoiding it can be described</div><div>as a=
 benefit.=C2=A0</div><div><br></div><div>I don&#39;t think the current case=
 is as bad as the other ones like</div><div>users needing to modify their q=
ueries or type-safety system</div><div>being broken. So personally I&#39;m =
not willing to creating some</div><div>thing new &amp; heavy. However I&#39=
;m open to see what others say.=C2=A0=C2=A0</div><div>=C2=A0</div></div><sp=
an class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D=
"gmail_signature"><div dir=3D"ltr">Best Regards<div>Andy Fan</div></div></d=
iv></div>

--0000000000005936420602f0ce9b--