Re: call the same pl/pgsql procedure twice in the same connection

From: Jan Wieck <janwieck(at)yahoo(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Jan Wieck <janwieck(at)yahoo(dot)com>, jack <datactrl(at)tpg(dot)com(dot)au>, pgsql-sql(at)postgresql(dot)org
Subject: Re: call the same pl/pgsql procedure twice in the same connection
Date: 2002-04-18 18:49:26
Message-ID: 200204181849.g3IInRM14849@saturn.janwieck.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

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.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Fduch the Pravking 2002-04-18 23:30:41 Re: DISTINCT ON ... without distinct null values ?
Previous Message Richard Huxton 2002-04-18 17:38:36 Re: SQL Query Optimization