Skip site navigation (1) Skip section navigation (2)

Plan invalidation

From: "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Plan invalidation
Date: 2007-04-03 14:02:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I noticed that the plan invalidation is not immediately effective.
Not sure whether it's worth fixing or has any other side-effects,
but thought would just post it.

I was testing the following scenario:

    session1                            session2

        (int a, int b);
                                 SET enable_seqscan = off
                                 PREPARE myplan AS SELECT * FROM TEST
                                           WHERE a = 100;
                                 EXPLAIN EXECUTE myplan; (seq scan)
    CREATE INDEX                        
                        ----->   EXPLAIN EXECUTE myplan (seq scan)
                                 EXPLAIN EXECUTE myplan (index scan)

The second "EXPLAIN" in session 2 uses seq scan because the plan
is not invalidated and replanned properly. Ideally it should have
used the index scan.

I traced it a bit and it seems that the invalidation messages
are not accepted in session 2 because the locks are already held
on the relation. At the end of the command, session 2 calls
CommandCounterIncrement() and gets the invalidation messages.
Hence the next EXPLAIN revalidates the plan properly.

May be this is not such an important issue. But I was wondering
if there are other places in the code where we might miss
or receive invalidation messages with a delay, mostly because
of *lack* of lock conflict ?





pgsql-hackers by date

Next:From: Tom LaneDate: 2007-04-03 14:15:18
Subject: Re: Modifying TOAST thresholds
Previous:From: Greg SmithDate: 2007-04-03 13:53:37
Subject: Re: Logging checkpoints and other slowdown causes

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group