This is a discussion on pgsql: Revert my bad decision of about a year ago to make within the pgsql Committers forums, part of the PostgreSQL category; --> Log Message: ----------- Revert my bad decision of about a year ago to make PortalDefineQuery responsible for copying the ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| Log Message: ----------- Revert my bad decision of about a year ago to make PortalDefineQuery responsible for copying the query string into the new Portal. Such copying is unnecessary in the common code path through exec_simple_query, and in this case it can be enormously expensive because the string might contain a large number of individual commands; we were copying the entire, long string for each command, resulting in O(N^2) behavior for N commands. (This is the cause of bug #4079.) A second problem with it is that PortalDefineQuery really can't risk error, because if it elog's before having set up the Portal, we will leak the plancache refcount that the caller is trying to hand off to the portal. So go back to the design in which the caller is responsible for making sure everything is copied into the portal if necessary. Modified Files: -------------- pgsql/src/backend/commands: portalcmds.c (r1.72 -> r1.73) (http://anoncvs.postgresql.org/cvsweb...1=1.72&r2=1.73) prepare.c (r1.84 -> r1.85) (http://anoncvs.postgresql.org/cvsweb...1=1.84&r2=1.85) pgsql/src/backend/executor: spi.c (r1.192 -> r1.193) (http://anoncvs.postgresql.org/cvsweb...1.192&r2=1.193) pgsql/src/backend/tcop: postgres.c (r1.547 -> r1.548) (http://anoncvs.postgresql.org/cvsweb...1.547&r2=1.548) pgsql/src/backend/utils/mmgr: portalmem.c (r1.108 -> r1.109) (http://anoncvs.postgresql.org/cvsweb...1.108&r2=1.109) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers |
| Thread Tools | |
| Display Modes | |
|
|