Re: How to get FK to use new index without restarting the database

From: Jayadevan M <Jayadevan(dot)Maymala(at)ibsplc(dot)com>
To: Eric Comeau <ecomeau(at)signiant(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org, pgsql-performance-owner(at)postgresql(dot)org
Subject: Re: How to get FK to use new index without restarting the database
Date: 2010-12-16 12:34:45
Message-ID: OFC47B4729.FAF27BE5-ON652577FB.0044D994-652577FB.00452962@ibsplc.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hello,
> Is there a way force the db to re-evaluate its execution plan for a FK
> without bouncing the DB?
>
> PostgreSQL 8.1.17
>
> In our latest release our developers have implemented some new foreign
> keys but forgot to create indexes on these keys.
>
> The problem surfaced at one of our client installs where a maintenance
> DELETE query was running for over 24 hrs. We have since then identified
> the missing indexes and have sent the client a script to create them,
> but in our testing we could not been able to get postgres to use the new

> index for the FK cascade delete without bouncing the database.
Did you try analyze? May be it will help.
http://www.postgresql.org/docs/9.0/static/sql-analyze.html

Regards,
Jayadevan

DISCLAIMER:

"The information in this e-mail and any attachment is intended only for
the person to whom it is addressed and may contain confidential and/or
privileged material. If you have received this e-mail in error, kindly
contact the sender and destroy all copies of the original communication.
IBS makes no warranty, express or implied, nor guarantees the accuracy,
adequacy or completeness of the information contained in this email or any
attachment and is not liable for any errors, defects, omissions, viruses
or for resultant loss or damage, if any, direct or indirect."

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Richard Huxton 2010-12-16 12:37:50 Re: performance libpq vs JDBC
Previous Message selvi88 2010-12-16 12:33:07 postgres performance tunning