Excerpts from Stephen Frost's message of vie ene 07 15:29:52 -0300 2011:
* Stephen Frost (sfr...@snowman.net) wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Making it part of DISCARD PLANS; and back-patching it to 8.3 where
DISCARD was introduced would be awesome for me. :)
On Fri, Jan 7, 2011 at 1:29 PM, Stephen Frost sfr...@snowman.net wrote:
#1. Add a new 'Top-but-removed-on-DISCARD' context and modify the PLs to
use that instead of TopMemoryContext and require any other contexts
they create to be children of it.
I'm guessing that just resetting the
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Jan 7, 2011 at 1:29 PM, Stephen Frost sfr...@snowman.net wrote:
#1. Add a new 'Top-but-removed-on-DISCARD' context and modify the PLs to
use that instead of TopMemoryContext and require any other contexts
they create to be
All,
Alright, so, the whole fn_extra stuff seems to be unrelated.. I'm not
sure when it's used (perhaps multiple calls to the same function in a
given query?), but the PLs have their own hash tables that they use for
storing functions that have been called. I had assumed that was done
through
On Sat, Jan 8, 2011 at 4:28 PM, Stephen Frost sfr...@snowman.net wrote:
Thoughts?
Unfortunately, we've officially exceeded my level of knowledge to the
point where I can't comment intelligently. Sorry :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
* Robert Haas (robertmh...@gmail.com) wrote:
If DISCARD ALL doesn't flush this stuff, I'd consider that an outright
bug. Does it?
No, it does not, based on my testing against 8.4.5:
Simple function:
CREATE OR REPLACE FUNCTION test_func() RETURNS boolean
AS $_$
On Fri, Jan 7, 2011 at 8:43 AM, Stephen Frost sfr...@snowman.net wrote:
To be honest, I agree it's a bug, and I would *love* to have it
back-patched, but I could see an argument for it to be something
explicit from DISCARD PLANS; and would hence require a grammar
change which isn't something
* Robert Haas (robertmh...@gmail.com) wrote:
Really it seems to me that changing the search path ought to discard
anything that might have been done differently had the search path
been different, but I don't think that's back-patch material.
I like that idea, but I agree it wouldn't be
* Stephen Frost (sfr...@snowman.net) wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Making it part of DISCARD PLANS; and back-patching it to 8.3 where
DISCARD was introduced would be awesome for me. :)
I'd need to look at this more closely before committing anything, but
at
Greetings,
Looking at discard all, I was a bit suprised that 'DISCARD PLANS;'
doesn't clear out cached stored procedures. To be honest, that's one
of the main reasons I'd see to use it. I thought there had been some
discussion in the archives related to invalidating stored procedure
On Thu, Jan 6, 2011 at 3:20 PM, Stephen Frost sfr...@snowman.net wrote:
Greetings,
Looking at discard all, I was a bit suprised that 'DISCARD PLANS;'
doesn't clear out cached stored procedures. To be honest, that's one
of the main reasons I'd see to use it. I thought there had been some
* Merlin Moncure (mmonc...@gmail.com) wrote:
this is a problem. under what circumstances would you want to discard
them and why? the main problem I see with cached plpgsql plans is
interactions with search_path -- but DISCARD might not be the best way
to attack that problem. There might be
On Thu, Jan 6, 2011 at 4:30 PM, Stephen Frost sfr...@snowman.net wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
this is a problem. under what circumstances would you want to discard
them and why? the main problem I see with cached plpgsql plans is
interactions with search_path -- but
* Merlin Moncure (mmonc...@gmail.com) wrote:
this has been discussed a couple of times -- a plausible alternative
might be to adjust the plan caching mechanism to organize the plan
cache around search_path. that way you get a separate plan per
search_path instance.
That would certainly be
On Thu, Jan 6, 2011 at 5:22 PM, Stephen Frost sfr...@snowman.net wrote:
If it's performance vs. correctness, you can guess what I'm going to
vote for, however, in this case, I can't see how either of the other
options would perform better than a discard-like approach. If people
are already
15 matches
Mail list logo
