Re: Index

Am 10.03.24 um 19:21 schrieb Rajesh Kumar:
> If we are deleting rows often.....I am talking ABT the possibility of
> index bloat.
>
> On Sun, 10 Mar 2024, 23:40 Ron Johnson, <ronljohnsonjr(at)gmail(dot)com> wrote:
>
> What does "if index is not managed" mean?
>
> On Sun, Mar 10, 2024 at 9:11 AM Rajesh Kumar
> <rajeshkumar(dot)dba09(at)gmail(dot)com> wrote:
>
> What will happen if index is not managed in this case?
>
> On Sun, 10 Mar 2024, 17:20 Holger Jakobs, <holger(at)jakobs(dot)com>
> wrote:
>
> Am 10.03.24 um 12:19 schrieb Rajesh Kumar:
> > Hi ,
> >
> > I have a table where size is increasing daily. In that
> table only
> > inserts and deletes happens. This table is referencing
> 15 other
> > tables. We have given delete cascade, so if a row is
> deleted in parent
> > table,  the matching records will also be deleted in
> those child tables.
> >
> > It is taking lot of time to delete. So, I am planning to
> create index
> > on those child tables.
> >
> > My question is, apart from inserts, I am only going to
> delete records
> > from those tables. How index improves performance for
> deleting
> > records? How index is affected or how to do index
> management in this case?
>
> Hi,
>
> Since every single row which is going to be deleted in the
> child tables
> has to be found, an index can be of great help here.
>
> Actually, in most (not all!) cases an index on foreign key
> columns makes
> sense.
>
> Regards,
>
> Holger
>
> --
> Holger Jakobs, Bergisch Gladbach, Tel. +49-178-9759012
>
Are your deleting arbitrary rows - or are the data timeseries, where you
delete all data of weeks or months?

If so, time-partition your tables and drop partitions when necessary.

If not, tune autovacuum or vacuum full your tables and indexes every now
and then. Or re-index concurrently sometimes.

--

Holger Jakobs, Bergisch Gladbach, Tel. +49-178-9759012

chat with me on Signal messenger
<https://signal.me/#eu/GpIP259bBne_JiBYJFvbZCLYJELhB-92nJfncACL1LUeBOphfXFFgLYYVXv_AGhg>