Horton

Thread

  1. REINDEX in tables

    Matthias Apitz <guru@unixarea.de> — 2023-10-25T09:24:02Z

    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.

  2. Re: REINDEX in tables

    Andreas Kretschmer <andreas@a-kretschmer.de> — 2023-10-25T09:33:11Z

    
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

  3. Re: REINDEX in tables

    Matthias Apitz <guru@unixarea.de> — 2023-10-25T09:57:30Z

    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.

  4. Re: REINDEX in tables

    Andreas Kretschmer <andreas@a-kretschmer.de> — 2023-10-25T09:59:38Z

    
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

  5. Re: REINDEX in tables

    Laurenz Albe <laurenz.albe@cybertec.at> — 2023-10-25T12:11:49Z

    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

  6. Re: REINDEX in tables

    Andreas Kretschmer <andreas@a-kretschmer.de> — 2023-10-25T12:14:49Z

    
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

  7. Re: REINDEX in tables

    Bruce Momjian <bruce@momjian.us> — 2023-10-25T13:17:17Z

    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.

  8. Re: REINDEX in tables

    Michael Paquier <michael@paquier.xyz> — 2023-10-25T23:33:00Z

    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