Thread

Commits

  1. doc: avoid saying "inheritance" ...

  1. doc phrase: "inheritance child"

    Justin Pryzby <pryzby@telsasoft.com> — 2022-05-25T01:32:48Z

    In this old sub-thread, we removed the use of word "partition" when it didn't
    mean "declarative partitioning".
    
    https://www.postgresql.org/message-id/flat/20180601213300.GT5164%40telsasoft.com#32efea8c1aa0e875d201873dac56e09c
    
    Now, I'm proposing to get rid of the phrase "inheritance child" when it also
    *does* apply to declarative partitioning.
    
  2. Re: doc phrase: "inheritance child"

    Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> — 2022-05-25T04:29:57Z

    Hi Justin,
    
    @@ -7306,7 +7306,7 @@ SCRAM-SHA-256$<replaceable>&lt;iteration
    count&gt;</replaceable>:<replaceable>&l
       <para>
        Normally there is one entry, with <structfield>stainherit</structfield>
    =
        <literal>false</literal>, for each table column that has been analyzed.
    -   If the table has inheritance children, a second entry with
    +   If the table has inheritance children or partitions, a second entry with
        <structfield>stainherit</structfield> = <literal>true</literal> is also
    created.  This row
        represents the column's statistics over the inheritance tree, i.e.,
        statistics for the data you'd see with
    
    For partitioned tables only the second entry makes sense. IIRC, we had done
    some work to remove the first entry. Can you please check whether a
    partitioned table also has two entries?
    
           <para>
    -       If true, the stats include inheritance child columns, not just the
    +       If true, the stats include child tables, not just the
    
    We are replacing columns with tables; is that intentional?
    
    Partitioned tables do not have their own stats, it's just aggregated
    partition stats.
    
    -   If the table has inheritance children, a second entry with
    +   If the table has inheritance children or partitions, a second entry with
        <structfield>stxdinherit</structfield> = <literal>true</literal> is
    also created.
        This row represents the statistics object over the inheritance tree,
    i.e.,
    
    Similar to the first comment. s/inheritance tree/inheritance or partition
    tree/ ?
    
    
    -       If true, the stats include inheritance child columns, not just the
    +       If true, the stats include child childs, not just the
            values in the specified relation
           </para></entry>
          </row>
    @@ -13152,7 +13152,7 @@ SELECT * FROM pg_locks pl LEFT JOIN
    pg_prepared_xacts ppx
            <structfield>inherited</structfield> <type>bool</type>
           </para>
           <para>
    -       If true, this row includes inheritance child columns, not just the
    +       If true, this row includes child tables, not just the
            values in the specified table
           </para></entry>
          </row>
    
    Replacing inheritance child "column" with "tables", is that intentional?
    
    Are these all the places where child/children need to be replaced by
    partitions?
    
    Now that the feature is old and also being used widely, it probably makes
    sense to mention partition where inheritance children is mentioned, if this
    double mention makes sense. But I think it's more than just the
    replacement. We need to rewrite or make modified copies of some of the
    sentences or paragraphs entirely. Esp. the things that apply to inheritance
    may not be applicable as is to partitioning and vice versa. We may be
    required to replace inheritance tree with partition tree in the nearby
    sentences.
    
    
    --
    Best Wishes,
    Ashutosh
    
  3. Re: doc phrase: "inheritance child"

    Amit Langote <amitlangote09@gmail.com> — 2022-05-27T03:47:18Z

    Hi,
    
    On Wed, May 25, 2022 at 1:30 PM Ashutosh Bapat
    <ashutosh.bapat@enterprisedb.com> wrote:
    > @@ -7306,7 +7306,7 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
    >    <para>
    >     Normally there is one entry, with <structfield>stainherit</structfield> =
    >     <literal>false</literal>, for each table column that has been analyzed.
    > -   If the table has inheritance children, a second entry with
    > +   If the table has inheritance children or partitions, a second entry with
    >     <structfield>stainherit</structfield> = <literal>true</literal> is also created.  This row
    >     represents the column's statistics over the inheritance tree, i.e.,
    >     statistics for the data you'd see with
    >
    > For partitioned tables only the second entry makes sense. IIRC, we had done some work to remove the first entry. Can you please check whether a partitioned table also has two entries?
    
    Don't think we've made any changes yet that get rid of the parent
    partitioned table's entry in pg_statistic:
    
    create table foo (a int) partition by list (a);
    create table foo1 partition of foo for values in (1);
    analyze foo;
    select starelid::regclass, stainherit from pg_statistic where
    starelid::regclass in (select relid from pg_partition_tree('foo'));
     starelid | stainherit
    ----------+------------
     foo      | t
     foo1     | f
    (2 rows)
    
    Maybe you're thinking of RangeTblEntry that the planner makes 2 copies
    for inheritance parents, but only 1 for partition parents as of
    e8d5dd6be79.
    
    --
    Thanks, Amit Langote
    EDB: http://www.enterprisedb.com
    
    
    
    
  4. Re: doc phrase: "inheritance child"

    Amit Langote <amitlangote09@gmail.com> — 2022-05-27T06:22:38Z

    On Wed, May 25, 2022 at 1:30 PM Ashutosh Bapat
    <ashutosh.bapat@enterprisedb.com> wrote:
    >        <para>
    > -       If true, the stats include inheritance child columns, not just the
    > +       If true, the stats include child tables, not just the
    >
    > We are replacing columns with tables; is that intentional?
    >
    > Partitioned tables do not have their own stats, it's just aggregated partition stats.
    > ...
    > -       If true, the stats include inheritance child columns, not just the
    > +       If true, the stats include child childs, not just the
    >         values in the specified relation
    >        </para></entry>
    >       </row>
    > @@ -13152,7 +13152,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
    >         <structfield>inherited</structfield> <type>bool</type>
    >        </para>
    >        <para>
    > -       If true, this row includes inheritance child columns, not just the
    > +       If true, this row includes child tables, not just the
    >         values in the specified table
    >        </para></entry>
    >       </row>
    >
    > Replacing inheritance child "column" with "tables", is that intentional?
    
    I was a bit confused by these too, though perhaps the original text is
    not as clear as it could be?  Would the following be a good rewrite:
    
    If true, the stats cover the contents not only of the specified table,
    but also of its child tables or partitions.  (If the table is
    partitioned, which contains no data by itself, the stats only cover
    the contents of partitions).
    
    Although, maybe the parenthetical is unnecessary.
    
    -- 
    Thanks, Amit Langote
    EDB: http://www.enterprisedb.com
    
    
    
    
  5. Re: doc phrase: "inheritance child"

    Justin Pryzby <pryzby@telsasoft.com> — 2022-06-30T09:55:36Z

    On Fri, May 27, 2022 at 03:22:38PM +0900, Amit Langote wrote:
    > On Wed, May 25, 2022 at 1:30 PM Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote:
    > >        <para>
    > > -       If true, the stats include inheritance child columns, not just the
    > > +       If true, the stats include child tables, not just the
    > >
    > > We are replacing columns with tables; is that intentional?
    > >
    > > Partitioned tables do not have their own stats, it's just aggregated partition stats.
    > > ...
    > > -       If true, the stats include inheritance child columns, not just the
    > > +       If true, the stats include child childs, not just the
    > >         values in the specified relation
    > >        </para></entry>
    > >       </row>
    > > @@ -13152,7 +13152,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
    > >         <structfield>inherited</structfield> <type>bool</type>
    > >        </para>
    > >        <para>
    > > -       If true, this row includes inheritance child columns, not just the
    > > +       If true, this row includes child tables, not just the
    > >         values in the specified table
    > >        </para></entry>
    > >       </row>
    > >
    > > Replacing inheritance child "column" with "tables", is that intentional?
    > 
    > I was a bit confused by these too, though perhaps the original text is
    > not as clear as it could be?  Would the following be a good rewrite:
    
    I updated the language to say "values from".  Is this better ?
    
    And rebased to include changes to 401f623c7.
    
    BTW nobody complained about my "child child" typo.
    
    -- 
    Justin
    
  6. Re: doc phrase: "inheritance child"

    Amit Langote <amitlangote09@gmail.com> — 2022-07-05T07:36:08Z

    On Thu, Jun 30, 2022 at 6:55 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
    > On Fri, May 27, 2022 at 03:22:38PM +0900, Amit Langote wrote:
    > > On Wed, May 25, 2022 at 1:30 PM Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote:
    > > >        <para>
    > > > -       If true, the stats include inheritance child columns, not just the
    > > > +       If true, the stats include child tables, not just the
    > > >
    > > > We are replacing columns with tables; is that intentional?
    > > >
    > > > Partitioned tables do not have their own stats, it's just aggregated partition stats.
    > > > ...
    > > > -       If true, the stats include inheritance child columns, not just the
    > > > +       If true, the stats include child childs, not just the
    > > >         values in the specified relation
    > > >        </para></entry>
    > > >       </row>
    > > > @@ -13152,7 +13152,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
    > > >         <structfield>inherited</structfield> <type>bool</type>
    > > >        </para>
    > > >        <para>
    > > > -       If true, this row includes inheritance child columns, not just the
    > > > +       If true, this row includes child tables, not just the
    > > >         values in the specified table
    > > >        </para></entry>
    > > >       </row>
    > > >
    > > > Replacing inheritance child "column" with "tables", is that intentional?
    > >
    > > I was a bit confused by these too, though perhaps the original text is
    > > not as clear as it could be?  Would the following be a good rewrite:
    >
    > I updated the language to say "values from".  Is this better ?
    
    Yes.
    
    -- 
    Thanks, Amit Langote
    EDB: http://www.enterprisedb.com
    
    
    
    
  7. Re: doc phrase: "inheritance child"

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2022-07-28T16:30:26Z

    On 2022-Jun-30, Justin Pryzby wrote:
    
    > I updated the language to say "values from".  Is this better ?
    > 
    > And rebased to include changes to 401f623c7.
    
    Applied to 15 and master, thanks.
    
    > BTW nobody complained about my "child child" typo.
    
    :-(
    
    BTW I didn't notice your annotation in the CF app until I had already
    pushed it and went there to update the status.
    
    -- 
    Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
    Maybe there's lots of data loss but the records of data loss are also lost.
    (Lincoln Yeoh)
    
    
    
    
  8. Re: doc phrase: "inheritance child"

    Justin Pryzby <pryzby@telsasoft.com> — 2022-07-29T13:29:15Z

    On Thu, Jul 28, 2022 at 06:30:26PM +0200, Alvaro Herrera wrote:
    > BTW I didn't notice your annotation in the CF app until I had already
    > pushed it and went there to update the status.
    
    Hmmm and I didn't see that you'd updated the status ... so done.
    Thanks for rebasifying it.
    
    -- 
    Justin