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

Re: Dropping of indexes with cached PL query plans

From: Jerry Sievers <jerry(at)jerrysievers(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: Dropping of indexes with cached PL query plans
Date: 2006-02-16 17:14:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Jerry Sievers <jerry(at)jerrysievers(dot)com> writes:
> > Any of these connections that may have previously executed PL
> > functions which planned an index lookup are now going to fault if same
> > index goes away.
> > Had wondered if a postmaster 'reload' would elicit a recompiling of
> > func query plans (did *not* see this in the docs but was hopeful...).
> Starting a fresh session (database connection) is sufficient, you need
> not bounce the postmaster as such.

Yes Tom, thanks.

Note that I am referring to the 'reload' operation, that is; simple
HUPping of postmaster.  But of course, this doesn't cause cached query
plans to be recalc'd anyway, as you point out below (at least, not

I wonder if you'd comment on the (apparently) useful workaround of
doing a CREATE or REPLACE FUNCTION on the PL funcs?

This does work, on 8.0 systems, though perhaps isn't a robust solution
for some other reason.

I do understand also that such a solution will *not* solve the same
problem as it relates to Postgres prepared statements.  As I
understant it, only the active session could deallocate and re-prepare
such a statement.

> We are looking at making replanning happen automatically after a schema
> change; I'm hopeful that that gets done for 8.2.

That would be excellent IMO.

Failing that, if systemic replanning is deemed too heavy to initiate
on any DDL change; something like  an administrator forced re-cacheing
might suffice.

Eg; pg_ctl recache  (SIGUSR1 or somesuch tells running sessions to
replan any cached queries).

At any rate, great work past and present.


Jerry Sievers   305 854-3001 (home)     WWW ECommerce Consultant
                305 321-1144 (mobile

In response to

pgsql-admin by date

Next:From: David BearDate: 2006-02-16 17:26:21
Subject: Re: hba conf ident sameuser not working
Previous:From: Tomeh, HusamDate: 2006-02-16 16:39:30
Subject: Re: Postgresql performance and tuning questions

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