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.

Here is an example of an added fk but missing index....

ALTER TABLE scheduled_job_arg ADD CONSTRAINT sjr_scheduled_job_id_fk
FOREIGN KEY (scheduled_job_id) REFERENCES scheduled_job (id)
ON UPDATE CASCADE ON DELETE CASCADE;

Thanks in Advance,
Eric

Search Discussions

  • Jayadevan M at Dec 16, 2010 at 12:37 pm
    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."
  • Eric Comeau at Dec 16, 2010 at 1:24 pm
    On 10-12-16 07:34 AM, Jayadevan M wrote:
    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
    Yes we did. Thanks for the suggestion.
    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."




  • Richard Huxton at Dec 16, 2010 at 12:39 pm

    On 16/12/10 12:12, Eric Comeau wrote:
    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.
    Well, an ongoing DELETE isn't going to see a new index. I'd have thought
    a new connection should though.

    --
    Richard Huxton
    Archonet Ltd
  • Tom Lane at Dec 16, 2010 at 4:28 pm

    Eric Comeau writes:
    Is there a way force the db to re-evaluate its execution plan for a FK
    without bouncing the DB?
    PostgreSQL 8.1.17
    You don't need to bounce the whole DB, but you will need to start fresh
    sessions. We didn't add automatic invalidation of those plans until 8.3.

    regards, tom lane
  • Eric Comeau at Dec 16, 2010 at 4:46 pm
    On 10-12-16 11:27 AM, Tom Lane wrote:

    Eric Comeau <ecomeau@signiant.com> writes:
    Is there a way force the db to re-evaluate its execution plan for a FK
    without bouncing the DB?
    PostgreSQL 8.1.17
    You don't need to bounce the whole DB, but you will need to start fresh
    sessions. We didn't add automatic invalidation of those plans until 8.3.

    regards, tom lane



    We confirmed that disconnecting and reconnecting resolves the issue.

    Thanks to all that helped.

    Eric
  • Eric Comeau at Dec 17, 2010 at 6:54 am

    On 10-12-16 11:27 AM, Tom Lane wrote:
    Eric Comeau<ecomeau@signiant.com> writes:
    Is there a way force the db to re-evaluate its execution plan for a FK
    without bouncing the DB?
    PostgreSQL 8.1.17
    You don't need to bounce the whole DB, but you will need to start fresh
    sessions. We didn't add automatic invalidation of those plans until 8.3.

    regards, tom lane
    We confirmed that disconnecting and reconnecting resolves the issue.

    Thanks to all that helped.

    I replied to Tom and the list yesterday from my e-mail, but I don't see
    my reply here, so it must be stuck in the ether somewhere....

    Eric

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-performance @
categoriespostgresql
postedDec 16, '10 at 12:24p
activeDec 17, '10 at 6:54a
posts7
users5
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase