Re: call the same pl/pgsql procedure twice in the same connection
От | Bruce Momjian |
---|---|
Тема | Re: call the same pl/pgsql procedure twice in the same connection |
Дата | |
Msg-id | 200204231615.g3NGFXa10160@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: call the same pl/pgsql procedure twice in the same connection (Jan Wieck <janwieck@yahoo.com>) |
Ответы |
Re: call the same pl/pgsql procedure twice in the same connection
|
Список | pgsql-sql |
Jan Wieck wrote: > Bruce Momjian wrote: > > Jan Wieck wrote: > > > Bruce Momjian wrote: > > > > > > > > Jan, instead of doing cache invalidation to fix temporary tables, can we > > > > disable cached plans for functions that use temporary tables? > > > > > > I was thinking of a different approach. Enhancing the SPI > > > manager to detect if a plan uses temporary objects and to > > > remember the original querystring in the SPI_plan. Having > > > callbacks when temp object beeing destroyed into the SPI > > > manager, causing it to reparse and plan on the next call to > > > SPI_execp() would do it for everything that uses SPI. > > > > I was merely proposing that preventing caching of functions ueing temp > > tables may be easier than trying to invalidation them on temp table > > destruction. > > It's neat to say "preventing caching of functions using ...", > now tell in detail how you detect that a function "is" using > a temp table? No, I don't mean how "you" can detect it, how > can the PL/pgSQL parser or executor detect it. And when do > you detect it? Remember that PL/pgSQL has delayed SPI > preparation? > > Second, it doesn't really look smart to me to prevent saving > of all query plans just because one of them uses a temp > table. Well, I assume you could spin through the plan at save time and look at every relation reference to see if it is a temp table. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-sql по дате отправления: