public inbox for [email protected]
help / color / mirror / Atom feedFrom: JoongHyuk Shin <[email protected]>
To: Tom Lane <[email protected]>
Cc: Amit Khandekar <[email protected]>
Cc: [email protected]
Subject: Re: Inconsistency in owner assignment between INDEX and STATISTICS
Date: Tue, 7 Apr 2026 19:34:54 +0900
Message-ID: <CACSdjfM4-mLKfVr7=g5_eSiOMtYAmVM1w1=kCf5QKSYwcDjNfA@mail.gmail.com> (raw)
In-Reply-To: <CACSdjfN6ydot=nibVF5__-Q7H7AFUG5r96EYbV9SWnM4VBmVyg@mail.gmail.com>
References: <CACSdjfMWcR7aJUDf6XNt_yaDi+riz3Ku4EQ-x3xA=Xx1209n2g@mail.gmail.com>
<CAJ3gD9eJE_c=eSbBjqAAg+-x2XOSgZ5uYqyAiy4TrJJwxEXyng@mail.gmail.com>
<CACSdjfPor9NRN4WiNZ5HmpdFn7q6dERHuZvaMxHMirXUYDC6_A@mail.gmail.com>
<[email protected]>
<CACSdjfN6ydot=nibVF5__-Q7H7AFUG5r96EYbV9SWnM4VBmVyg@mail.gmail.com>
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 AM Shin Berg <[email protected]> wrote:
> 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 AM Tom Lane <[email protected]> wrote:
>
>> Shin Berg <[email protected]> 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 — it's tied to the table and intentionally
>> 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
>>
>
view thread (7+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Inconsistency in owner assignment between INDEX and STATISTICS
In-Reply-To: <CACSdjfM4-mLKfVr7=g5_eSiOMtYAmVM1w1=kCf5QKSYwcDjNfA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox