On 12/20/2012 4:47 PM, Dimitri Fontaine wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> The reason this fails is that you've got a half-megabyte source string,
>> and each of the 11000 plans that are due to be created from it saves
>> its own copy of the source string. Hence, 5500 megabytes needed just
>> for source strings.
>>
>> We could possibly fix this by inventing some sort of reference-sharing
>> arrangement (which'd be complicated and fragile) or by not storing the
>> source strings with the plans (which'd deal a serious blow to our
>> ability to provide helpful error messages). Neither answer seems
>> appealing.
>
> I don't readily see how complicated and fragile it would be, it looks
> like a hash table of symbols pointing to source strings and a reference
> counting, and each plan would need to reference that symbol. Now maybe
> that's what you call complicated and fragile, and even if not, I'm not
> really sure it would pull its weight. The use case of sending over and
> over again *in a given session* the exact same query string without
> using PREPARE/EXECUTE looks like quite tiny.
>
That sounds like a bit of overkill to me.
Don't all the plans result as a plan list from a multi-statement query
string, which was parsed into a query tree "list" and each single query
tree then planned? I don't think there is any way that a single one of
those trees (parse or plan) will be free'd separately. If that is true,
then proper usage of memory contexts would make reference counting
obsolete, even though all plans refer to the same copy.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin