Re: Partitioned index can be not dumped

Поиск
Список
Период
Сортировка
Искать
От
Álvaro Herrera
Тема
Re: Partitioned index can be not dumped
Дата
Msg-id
202106302157.dh4gl7tu2v2x@alvherre.pgsql
Ответ на
Список
Дерево обсуждения
Partitioned index can be not dumped Alexander Pyhalov <a.pyhalov@postgrespro.ru>
Re: Partitioned index can be not dumped Alexander Pyhalov <a.pyhalov@postgrespro.ru>
Re: Partitioned index can be not dumped Álvaro Herrera <alvherre@alvh.no-ip.org>
Re: Partitioned index can be not dumped Álvaro Herrera <alvherre@alvh.no-ip.org>
Re: Partitioned index can be not dumped Alexander Pyhalov <a.pyhalov@postgrespro.ru>
Re: Partitioned index can be not dumped Álvaro Herrera <alvherre@alvh.no-ip.org>
Re: Partitioned index can be not dumped Zhihong Yu <zyu@yugabyte.com>
Re: Partitioned index can be not dumped Álvaro Herrera <alvherre@alvh.no-ip.org>
Re: Partitioned index can be not dumped Zhihong Yu <zyu@yugabyte.com>
Re: Partitioned index can be not dumped Álvaro Herrera <alvherre@alvh.no-ip.org>
On 2021-Jun-30, Zhihong Yu wrote:

> Hi,
> In that case, I wonder whether nindexes can be negated following the call
> to vac_open_indexes().
> 
>         vac_open_indexes(onerel, AccessShareLock, &nindexes, &Irel);
> +       nindexes = -nindexes;
> 
> That way, hasindex can be dropped.
> vac_update_relstats() call would become:
> 
>         vac_update_relstats(onerel, -1, totalrows,
> -                           0, false, InvalidTransactionId,
> +                           0, nindexes != 0, InvalidTransactionId,

Perhaps this works, but I don't think it's a readability improvement.

> My thinking is that without hasindex, the code is easier to maintain.

You have one less variable but one additional concept (negative
nindexes).  It doesn't seem easier to me, TBH, rather the opposite.

-- 
Álvaro Herrera                            39°49'30"S 73°17'W
                               https://www.EnterpriseDB.com/


В списке pgsql-hackers по дате отправления
От: Zhihong Yu
Дата:
От: Bruce Momjian
Дата:
FAQ