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.
What does "if index is not managed" mean?
What will happen if index is not managed in this case?
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.