Re: [HACKERS] Cached plans and statement generalization

Поиск
Список
Период
Сортировка
От Doug Doole
Тема Re: [HACKERS] Cached plans and statement generalization
Дата
Msg-id CAP6UvaO9bS8+U-Upt-1Fkn7tgUyNW_BiCFbh9a4LgcHqh84kQw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Cached plans and statement generalization  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] Cached plans and statement generalization  (Serge Rielau <serge@rielau.com>)
Re: [HACKERS] Cached plans and statement generalization  (Doug Doole <ddoole@salesforce.com>)
Список 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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: [HACKERS] Cached plans and statement generalization
Следующее
От: "Finnerty, Jim"
Дата:
Сообщение: Re: [HACKERS] Cached plans and statement generalization