On 12/20/2012 4:47 PM, Dimitri Fontaine wrote:
Tom Lane <[email protected]> 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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
