MIME-Version: 1.0
References: 
 <CACSdjfMWcR7aJUDf6XNt_yaDi+riz3Ku4EQ-x3xA=Xx1209n2g@mail.gmail.com>
 <CAJ3gD9eJE_c=eSbBjqAAg+-x2XOSgZ5uYqyAiy4TrJJwxEXyng@mail.gmail.com>
 <CACSdjfPor9NRN4WiNZ5HmpdFn7q6dERHuZvaMxHMirXUYDC6_A@mail.gmail.com>
 <2119849.1773605379@sss.pgh.pa.us>
 <CACSdjfN6ydot=nibVF5__-Q7H7AFUG5r96EYbV9SWnM4VBmVyg@mail.gmail.com>
In-Reply-To: 
 <CACSdjfN6ydot=nibVF5__-Q7H7AFUG5r96EYbV9SWnM4VBmVyg@mail.gmail.com>
From: JoongHyuk Shin <sjh910805@gmail.com>
Date: Tue, 7 Apr 2026 19:34:54 +0900
Message-ID: 
 <CACSdjfM4-mLKfVr7=g5_eSiOMtYAmVM1w1=kCf5QKSYwcDjNfA@mail.gmail.com>
Subject: Re: Inconsistency in owner assignment between INDEX and STATISTICS
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Khandekar <amitdkhan.pg@gmail.com>,
 pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000002b5fe0064edc5664"
Archived-At: 
 <https://www.postgresql.org/message-id/CACSdjfM4-mLKfVr7%3Dg5_eSiOMtYAmVM1w1%3DkCf5QKSYwcDjNfA%40mail.gmail.com>
Precedence: bulk

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

One related thing I noticed.
Unlike CREATE INDEX, CREATE STATISTICS on a partitioned table does not
propagate to child partitions.
Is that intentional, or simply not implemented yet?

In practice, if you create statistics on a partitioned parent and then
EXPLAIN a WHERE query,
the planner doesn't use the stats because after partition pruning it looks
at the child's statistics,
where none exist. You have to create statistics on each child explicitly to
get the benefit.

If the answer is "create stats per partition yourself", that's fine.
Just wanted to confirm whether this is by design.

On Mon, Mar 16, 2026 at 10:15=E2=80=AFAM Shin Berg <sjh910805@gmail.com> wr=
ote:

> Thank you for the additional context, Tom. That makes the design intent
> much clearer.
> Cross-table statistics, if realized, would be a significant improvement
> for join cardinality estimation; looking forward to seeing that develop.
>
> Regards,
> Joshua Shin
>
> On Mon, Mar 16, 2026 at 5:09=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrot=
e:
>
>> Shin Berg <sjh910805@gmail.com> writes:
>> > Thank you for the detailed feedback, Amit.
>> > You're right on both points. I had been comparing STATISTICS against
>> INDEX
>> > and treating the difference as an inconsistency, but as you point out,
>> > INDEX ownership is special =E2=80=94 it's tied to the table and intent=
ionally
>> not
>> > user-adjustable. STATISTICS follows the same ownership model as VIEW
>> (the
>> > creator becomes the owner), which is consistent and by design.
>>
>> One point that was not mentioned is that while indexes are necessarily
>> tied to a single table, statistics objects might not always be.  The
>> long-term hope is to allow statistics on cross-table combinations of
>> columns, which is why the syntax was intentionally set up to look like
>> SELECT.  So, just like views, it's reasonable to give them independent
>> ownership.
>>
>>                         regards, tom lane
>>
>

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

<div dir=3D"ltr">One related thing I noticed.<br>Unlike CREATE INDEX, CREAT=
E STATISTICS on a partitioned table does not propagate to child partitions.=
 <br>Is that intentional, or simply not implemented yet?<br><br>In practice=
, if you create statistics on a partitioned parent and then EXPLAIN a WHERE=
 query, <br>the planner doesn&#39;t use the stats because after partition p=
runing it looks at the child&#39;s statistics, <br>where none exist. You ha=
ve to create statistics on each child explicitly to get the benefit.<br><br=
>If the answer is &quot;create stats per partition yourself&quot;, that&#39=
;s fine.<br>Just wanted to confirm whether this is by design.<br></div><br>=
<div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"=
gmail_attr">On Mon, Mar 16, 2026 at 10:15=E2=80=AFAM Shin Berg &lt;<a href=
=3D"mailto:sjh910805@gmail.com">sjh910805@gmail.com</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"><div dir=3D"ltr">Thank y=
ou for the additional context, Tom. That makes the design intent much clear=
er. <br>Cross-table statistics, if realized, would be a significant improve=
ment for join cardinality estimation; looking forward to seeing that develo=
p.<br><br>Regards,<br>Joshua Shin</div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 16, 2026 at 5:09=E2=80=AFAM To=
m Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us" target=3D"_blank">tgl@sss.p=
gh.pa.us</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-le=
ft:1ex">Shin Berg &lt;<a href=3D"mailto:sjh910805@gmail.com" target=3D"_bla=
nk">sjh910805@gmail.com</a>&gt; writes:<br>
&gt; Thank you for the detailed feedback, Amit.<br>
&gt; You&#39;re right on both points. I had been comparing STATISTICS again=
st INDEX<br>
&gt; and treating the difference as an inconsistency, but as you point out,=
<br>
&gt; INDEX ownership is special =E2=80=94 it&#39;s tied to the table and in=
tentionally not<br>
&gt; user-adjustable. STATISTICS follows the same ownership model as VIEW (=
the<br>
&gt; creator becomes the owner), which is consistent and by design.<br>
<br>
One point that was not mentioned is that while indexes are necessarily<br>
tied to a single table, statistics objects might not always be.=C2=A0 The<b=
r>
long-term hope is to allow statistics on cross-table combinations of<br>
columns, which is why the syntax was intentionally set up to look like<br>
SELECT.=C2=A0 So, just like views, it&#39;s reasonable to give them indepen=
dent<br>
ownership.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 regards, tom lane<br>
</blockquote></div>
</blockquote></div>

--0000000000002b5fe0064edc5664--