Re: Improve automatic analyze messages for inheritance trees - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Improve automatic analyze messages for inheritance trees
Date
Msg-id CA+U5nMKk_tRA6nXFOu+oGEXBqEHLPoWDaf_Hmmk7Zg7ipPBTPw@mail.gmail.com
Whole thread Raw
In response to Re: Improve automatic analyze messages for inheritance trees  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
On 30 October 2014 03:30, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:
> (2014/10/17 18:35), Etsuro Fujita wrote:
>>
>> (2014/10/16 17:17), Simon Riggs wrote:
>>>
>>> Would it be useful to keep track of how many tables just got analyzed?
>>>
>>> i.e. analyze of foo (including N inheritance children)
>>
>>
>> I think that's a good idea.  So, I'll update the patch.
>
>
> Done.  Attached is an updated version of the patch.
>
> Thanks for the comment!

The patch was kinda ok, but we have deeper problems.

If we have a 3 level hierarchy like foo->(p1, p2->(p4), p3)
then we still report this pretty strangely
LOG:  automatic analyze of table "postgres.public.p1" system usage:
CPU 0.00s/0.00u sec elapsed 0.05 sec
LOG:  automatic analyze of table "postgres.public.foo" system usage:
CPU 0.00s/0.00u sec elapsed 0.04 sec
LOG:  automatic analyze of table "postgres.public.foo" (including 3
inheritance children) system usage: CPU 0.00s/0.01u sec elapsed 0.12
sec
LOG:  automatic analyze of table "postgres.public.p4" system usage:
CPU 0.00s/0.00u sec elapsed 0.00 sec

notice that p4 is not included as an inheritance child, even though it
most surely is. Why is p4 reported, when p1, p2 and p3 are not?

and I notice psql reports this incorrectly also

postgres=# \d+ foo
                         Table "public.foo" Column  |  Type   | Modifiers | Storage | Stats target | Description

----------+---------+-----------+---------+--------------+-------------
?column? | integer |           | plain   |              |

Child tables: p1,             p2,             p3

>>No mention of grandchildren...

Not your fault, but this patch doesn't sufficiently improve the
situation to commit it, yet.

Sorry, patch returned with feedback, for now.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Patch to support SEMI and ANTI join removal
Next
From: Simon Riggs
Date:
Subject: Re: New Event Trigger: table_rewrite