Thread: REINDEX in tables
We have a client who run REINDEX in certain tables of the database of
our application (on Linux with PostgreSQL 13.x):
REINDEX TABLE CONCURRENTLY d83last;
REINDEX TABLE CONCURRENTLY d86plz;
REINDEX TABLE CONCURRENTLY ig_memtable;
REINDEX TABLE CONCURRENTLY ig_dictionary;
REINDEX TABLE CONCURRENTLY ig_dictionary;
REINDEX TABLE CONCURRENTLY d50zweig ;
REINDEX TABLE CONCURRENTLY d50zweig ;
We as the software vendor and support, do not use or recommend this
procedure, because we have own SQL files for creating or deleting
indices in the around 400 tables.
The client is now concerned about the issue that the number of
rows in some of the above tables has increased. Is this possible?
Thanks
matthias
--
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia.
Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.
Am 25.10.23 um 11:24 schrieb Matthias Apitz: > We have a client who run REINDEX in certain tables of the database of > our application (on Linux with PostgreSQL 13.x): > > REINDEX TABLE CONCURRENTLY d83last; > REINDEX TABLE CONCURRENTLY d86plz; > REINDEX TABLE CONCURRENTLY ig_memtable; > REINDEX TABLE CONCURRENTLY ig_dictionary; > REINDEX TABLE CONCURRENTLY ig_dictionary; > REINDEX TABLE CONCURRENTLY d50zweig ; > REINDEX TABLE CONCURRENTLY d50zweig ; > > We as the software vendor and support, do not use or recommend this > procedure, because we have own SQL files for creating or deleting > indices in the around 400 tables. > > The client is now concerned about the issue that the number of > rows in some of the above tables has increased. Is this possible? In principle, there is nothing wrong with doing this in a maintenance window, for example. Regards, Andreas -- Andreas Kretschmer - currently still (garden leave) Technical Account Manager (TAM) www.enterprisedb.com
El día miércoles, octubre 25, 2023 a las 11:33:11 +0200, Andreas Kretschmer escribió:
> Am 25.10.23 um 11:24 schrieb Matthias Apitz:
> > We have a client who run REINDEX in certain tables of the database of
> > our application (on Linux with PostgreSQL 13.x):
> >
> > REINDEX TABLE CONCURRENTLY d83last;
> > REINDEX TABLE CONCURRENTLY d86plz;
> > REINDEX TABLE CONCURRENTLY ig_memtable;
> > REINDEX TABLE CONCURRENTLY ig_dictionary;
> > REINDEX TABLE CONCURRENTLY ig_dictionary;
> > REINDEX TABLE CONCURRENTLY d50zweig ;
> > REINDEX TABLE CONCURRENTLY d50zweig ;
> >
> > We as the software vendor and support, do not use or recommend this
> > procedure, because we have own SQL files for creating or deleting
> > indices in the around 400 tables.
> >
> > The client is now concerned about the issue that the number of
> > rows in some of the above tables has increased. Is this possible?
>
> In principle, there is nothing wrong with doing this in a maintenance
> window, for example.
But, this wasn't the question. It was: can it happen that the number of
rows in thze table will increase by this operation?
matthias
--
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.
Am 25.10.23 um 11:57 schrieb Matthias Apitz: > El día miércoles, octubre 25, 2023 a las 11:33:11 +0200, Andreas Kretschmer escribió: > >> Am 25.10.23 um 11:24 schrieb Matthias Apitz: >>> We have a client who run REINDEX in certain tables of the database of >>> our application (on Linux with PostgreSQL 13.x): >>> >>> REINDEX TABLE CONCURRENTLY d83last; >>> REINDEX TABLE CONCURRENTLY d86plz; >>> REINDEX TABLE CONCURRENTLY ig_memtable; >>> REINDEX TABLE CONCURRENTLY ig_dictionary; >>> REINDEX TABLE CONCURRENTLY ig_dictionary; >>> REINDEX TABLE CONCURRENTLY d50zweig ; >>> REINDEX TABLE CONCURRENTLY d50zweig ; >>> >>> We as the software vendor and support, do not use or recommend this >>> procedure, because we have own SQL files for creating or deleting >>> indices in the around 400 tables. >>> >>> The client is now concerned about the issue that the number of >>> rows in some of the above tables has increased. Is this possible? >> In principle, there is nothing wrong with doing this in a maintenance >> window, for example. > But, this wasn't the question. It was: can it happen that the number of > rows in thze table will increase by this operation? no, reindex will not add rows to the table. Regards, Andreas -- Andreas Kretschmer - currently still (garden leave) Technical Account Manager (TAM) www.enterprisedb.com
On Wed, 2023-10-25 at 11:59 +0200, Andreas Kretschmer wrote: > Am 25.10.23 um 11:57 schrieb Matthias Apitz: > > El día miércoles, octubre 25, 2023 a las 11:33:11 +0200, Andreas Kretschmer escribió: > > > Am 25.10.23 um 11:24 schrieb Matthias Apitz: > > > > We have a client who run REINDEX in certain tables of the database of > > > > our application (on Linux with PostgreSQL 13.x): > > > > > > > > REINDEX TABLE CONCURRENTLY d83last; > > > > REINDEX TABLE CONCURRENTLY d86plz; > > > > REINDEX TABLE CONCURRENTLY ig_memtable; > > > > REINDEX TABLE CONCURRENTLY ig_dictionary; > > > > REINDEX TABLE CONCURRENTLY ig_dictionary; > > > > REINDEX TABLE CONCURRENTLY d50zweig ; > > > > REINDEX TABLE CONCURRENTLY d50zweig ; > > > > > > > > We as the software vendor and support, do not use or recommend this > > > > procedure, because we have own SQL files for creating or deleting > > > > indices in the around 400 tables. > > > > > > > > The client is now concerned about the issue that the number of > > > > rows in some of the above tables has increased. Is this possible? > > > > no, reindex will not add rows to the table. But if the indexes were corrupted before the REINDEX, it is possible that a query that didn't find a result before the REINDEX can find one afterwards. Yours, Laurenz Albe
Am 25.10.23 um 14:11 schrieb Laurenz Albe: > On Wed, 2023-10-25 at 11:59 +0200, Andreas Kretschmer wrote: >> Am 25.10.23 um 11:57 schrieb Matthias Apitz: >>> El día miércoles, octubre 25, 2023 a las 11:33:11 +0200, Andreas Kretschmer escribió: >>>> Am 25.10.23 um 11:24 schrieb Matthias Apitz: >>>>> We have a client who run REINDEX in certain tables of the database of >>>>> our application (on Linux with PostgreSQL 13.x): >>>>> >>>>> REINDEX TABLE CONCURRENTLY d83last; >>>>> REINDEX TABLE CONCURRENTLY d86plz; >>>>> REINDEX TABLE CONCURRENTLY ig_memtable; >>>>> REINDEX TABLE CONCURRENTLY ig_dictionary; >>>>> REINDEX TABLE CONCURRENTLY ig_dictionary; >>>>> REINDEX TABLE CONCURRENTLY d50zweig ; >>>>> REINDEX TABLE CONCURRENTLY d50zweig ; >>>>> >>>>> We as the software vendor and support, do not use or recommend this >>>>> procedure, because we have own SQL files for creating or deleting >>>>> indices in the around 400 tables. >>>>> >>>>> The client is now concerned about the issue that the number of >>>>> rows in some of the above tables has increased. Is this possible? >> no, reindex will not add rows to the table. > But if the indexes were corrupted before the REINDEX, it is possible that > a query that didn't find a result before the REINDEX can find one afterwards. Thanks for the addition my friend, that's correct and could be an explanation here. Andreas -- Andreas Kretschmer - currently still (garden leave) Technical Account Manager (TAM) www.enterprisedb.com
On Wed, Oct 25, 2023 at 02:14:49PM +0200, Andreas Kretschmer wrote: > Am 25.10.23 um 14:11 schrieb Laurenz Albe: > > On Wed, 2023-10-25 at 11:59 +0200, Andreas Kretschmer wrote: > > > Am 25.10.23 um 11:57 schrieb Matthias Apitz: > > > > El día miércoles, octubre 25, 2023 a las 11:33:11 +0200, Andreas Kretschmer escribió: > > > > > Am 25.10.23 um 11:24 schrieb Matthias Apitz: > > > > > > We have a client who run REINDEX in certain tables of the database of > > > > > > our application (on Linux with PostgreSQL 13.x): > > > > > > > > > > > > REINDEX TABLE CONCURRENTLY d83last; > > > > > > REINDEX TABLE CONCURRENTLY d86plz; > > > > > > REINDEX TABLE CONCURRENTLY ig_memtable; > > > > > > REINDEX TABLE CONCURRENTLY ig_dictionary; > > > > > > REINDEX TABLE CONCURRENTLY ig_dictionary; > > > > > > REINDEX TABLE CONCURRENTLY d50zweig ; > > > > > > REINDEX TABLE CONCURRENTLY d50zweig ; > > > > > > > > > > > > We as the software vendor and support, do not use or recommend this > > > > > > procedure, because we have own SQL files for creating or deleting > > > > > > indices in the around 400 tables. > > > > > > > > > > > > The client is now concerned about the issue that the number of > > > > > > rows in some of the above tables has increased. Is this possible? > > > no, reindex will not add rows to the table. > > But if the indexes were corrupted before the REINDEX, it is possible that > > a query that didn't find a result before the REINDEX can find one afterwards. > > Thanks for the addition my friend, that's correct and could be an > explanation here. However, if that is happening, there is something seriously wrong, perhaps bad hardware. I would find the cause of this corruption. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
On Wed, Oct 25, 2023 at 11:33:11AM +0200, Andreas Kretschmer wrote: > Am 25.10.23 um 11:24 schrieb Matthias Apitz: >> We have a client who run REINDEX in certain tables of the database of >> our application (on Linux with PostgreSQL 13.x): >> >> REINDEX TABLE CONCURRENTLY d83last; >> REINDEX TABLE CONCURRENTLY d86plz; >> REINDEX TABLE CONCURRENTLY ig_memtable; >> REINDEX TABLE CONCURRENTLY ig_dictionary; >> REINDEX TABLE CONCURRENTLY ig_dictionary; >> REINDEX TABLE CONCURRENTLY d50zweig ; >> REINDEX TABLE CONCURRENTLY d50zweig ; >> >> We as the software vendor and support, do not use or recommend this >> procedure, because we have own SQL files for creating or deleting >> indices in the around 400 tables. >> >> The client is now concerned about the issue that the number of >> rows in some of the above tables has increased. Is this possible? > > In principle, there is nothing wrong with doing this in a maintenance > window, for example. If you have a maintenance window where your production server is not going to be active, you may want to just do a more aggressive REINDEX without CONCURRENTLY as that's going to be cheaper and faster. CONCURRENTLY is useful even in non-maintenance cases as it allows concurrent reads and writes to happen on the index while running the operation. CONCURRENTLY is much slower of course, as it needs to wait two times for older snapshots held by concurrent sessions when the index build is finished and when the index built gets validated. -- Michael