Bruce Momjian writes:
> Tom Lane wrote:
>> Did anybody do any performance measurements to demonstrate that this
>> code has a reason to live? Because if I don't see some, I'm going
>> to rip it out.
> Did we decide to keep the cache in attoptcache.c? Is this a TODO?
It's still a TODO, I think
Tom Lane wrote:
> So while poking at a recent example from Marc Cousin (hundreds of tables
> each with 1000 attributes) I observed that a simple ANALYZE would bloat
> the backend process to the tune of several hundred megabytes. I think
> there is a leak in CacheMemoryContext, but haven't tracked
On Tue, Mar 1, 2011 at 1:15 PM, Tom Lane wrote:
> Did anybody do any performance measurements to demonstrate that this
> code has a reason to live? Because if I don't see some, I'm going
> to rip it out.
No, I have to admit I didn't do that. Might be worth doing some
before you commit the rip-o
So while poking at a recent example from Marc Cousin (hundreds of tables
each with 1000 attributes) I observed that a simple ANALYZE would bloat
the backend process to the tune of several hundred megabytes. I think
there is a leak in CacheMemoryContext, but haven't tracked it down yet.
But I also
