On Wed, Nov 02, 2005 at 02:04:09PM -0500, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > BTW, that's a reversal from what I was originally arguing for, which was > > due to the performance penalty associated with --enable-cassert. My > > client is now running with Tom's suggestion of commenting out > > CLOBBER_FREED_MEMORY and MEMORY_CONTEXT_CHECKING and performance is > > good. It appears to be as good as it was with asserts disabled. > > Interesting. I've always wondered whether the "debug_assertions" GUC > variable is worth the electrons it's printed on. If you are running > with asserts active, that variable actually slows things down, by > requiring an additional bool test for every Assert. I suppose the > motivation was to allow the same compiled executable to be used for both > assert-enabled and assert-disabled runs, but how many people really need > that capability?
Not sure how that relates to CLOBBER_FREED_MEMORY and MEMORY_CONTEXT_CHECKING :P, but I agree that it doesn't make sense to have a GUC, at least not if asserts default to being compiled out. Hrm... does debug_assertions end up changing assert_enabled? BTW, is MEMORY_CONTEXT_CHECKING that expensive? It seems like it shouldn't be, but I'm only guessing at what exactly it does... -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
