Re: Autovacuum on partitioned table

Поиск
Список
Период
Сортировка
От yuzuko
Тема Re: Autovacuum on partitioned table
Дата
Msg-id CAKkQ508nu-YVDmoDef9riW5ApoOB0RG51S1ADuFG4_yvqRnSOQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Autovacuum on partitioned table  (yuzuko <yuzukohosoya@gmail.com>)
Ответы Re: Autovacuum on partitioned table  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Autovacuum on partitioned table (autoanalyze)  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
Hello,

> > > > +      */
> > > > +     if (IsAutoVacuumWorkerProcess() &&
> > > > +             rel->rd_rel->relispartition &&
> > > > +             !(rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE))
> > >
> > > I'm not sure I understand why we do this only on autovac. Why not all
> > > analyzes?
> >
> > +1.  If there is a reason, it should at least be documented in the
> > comment above.
> >
> When we analyze partitioned table by ANALYZE command,
> all inheritors including partitioned table are analyzed
> at the same time.  In this case, if we call pgstat_report_partanalyze,
> partitioned table's changes_since_analyze is updated
> according to the number of analyzed tuples of partitions
> as follows.  But I think it should be 0.
>
> \d+ p
>                                Partitioned table "public.p"
>  Column |  Type   | Collation | Nullable | Default | Storage | Stats
> target | Description
> --------+---------+-----------+----------+---------+---------+--------------+-------------
>  i      | integer |           |          |         | plain   |              |
> Partition key: RANGE (i)
> Partitions: p_1 FOR VALUES FROM (0) TO (100),
>                  p_2 FOR VALUES FROM (100) TO (200)
>
> insert into p select * from generate_series(0,199);
> INSERT 0 200
>
> (before analyze)
> -[ RECORD 1 ]-------+------------------
> relname             | p
> n_mod_since_analyze | 0
> -[ RECORD 2 ]-------+------------------
> relname             | p_1
> n_mod_since_analyze | 100
> -[ RECORD 3 ]-------+------------------
> relname             | p_2
> n_mod_since_analyze | 100
>
> (after analyze)
> -[ RECORD 1 ]-------+------------------
> relname             | p
> n_mod_since_analyze | 200
> -[ RECORD 2 ]-------+------------------
> relname             | p_1
> n_mod_since_analyze | 0
> -[ RECORD 3 ]-------+------------------
> relname             | p_2
> n_mod_since_analyze | 0
>
>
> I think if we analyze partition tree in order from leaf partitions
> to root table, this problem can be fixed.
> What do you think about it?
>

Attach the new patch fixes the above problem.  Also, This patch
includes modifications accoring to all comments Alvaro and Amit
mentioned before in this thread.

-- 
Best regards,
Yuzuko Hosoya
NTT Open Source Software Center

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Auxiliary Processes and MyAuxProc
Следующее
От: Tom Lane
Дата:
Сообщение: Re: proposal: new polymorphic types - commontype and commontypearray