Re: [HACKERS] Cached plans and statement generalization - Mailing list pgsql-hackers

From Doug Doole
Subject Re: [HACKERS] Cached plans and statement generalization
Date
Msg-id CAP6UvaO9bS8+U-Upt-1Fkn7tgUyNW_BiCFbh9a4LgcHqh84kQw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Cached plans and statement generalization  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Cached plans and statement generalization  (Serge Rielau <serge@rielau.com>)
Re: [HACKERS] Cached plans and statement generalization  (Doug Doole <ddoole@salesforce.com>)
List pgsql-hackers
(FWIW, on this list we don't do top-quotes)

I know. Forgot and just did "reply all". My bad.

It's not always that simple, at least in postgres, unless you disregard
search_path.  Consider e.g. cases like

CREATE SCHEMA a;
CREATE SCHEMA b;
CREATE TABLE a.foobar(somecol int);
SET search_patch = 'b,a';
SELECT * FROM foobar;
CREATE TABLE b.foobar(anothercol int);
SELECT * FROM foobar; -- may not be cached plan from before!

it sounds - my memory of DB2 is very faint, and I never used it much -
like similar issues could arise in DB2 too?

DB2 does handle this case. Unfortunately I don't know the details of how it worked though.

A naive option would be to invalidate anything that depends on table or view *.FOOBAR. You could probably make it a bit smarter by also requiring that schema A appear in the path.

- Doug

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: [HACKERS] Cached plans and statement generalization
Next
From: "Finnerty, Jim"
Date:
Subject: Re: [HACKERS] Cached plans and statement generalization