pike.git / lib / modules / Sql.pmod / pgsql.pike

version» Context lines:

pike.git/lib/modules/Sql.pmod/pgsql.pike:1892:    preparedname=    (portal._unnamedstatementkey=    (syncparse?unnamedstatement->lock:unnamedstatement->trylock)(1))    ? "" : PTSTMTPREFIX+int2hex(ptstmtcount++);    else if(syncparse)    portal._unnamedstatementkey=unnamedstatement->lock(1);    // Even though the protocol doesn't require the Parse command to be    // followed by a flush, it makes a VERY noticeable difference in    // performance if it is omitted; seems like a flaw in the PostgreSQL    // server v8.3.3 +  // In v8.4 and later, things speed up slightly when it is omitted.    PD("Parse statement %O=%O\n",preparedname,q);    plugbuffer=c->start()->add_int8('P') -  ->add_hstring(({preparedname,0,q,"\0\0\0"}),4,4)->add(PGFLUSH); +  ->add_hstring(({preparedname,0,q,"\0\0\0"}),4,4); //->add(PGFLUSH);    }    portal._preparedname=preparedname;    if(!tp || !tp.datatypeoid) {    PD("Describe statement %O\n",preparedname);    (plugbuffer||c->start())->add_int8('D')    ->add_hstring(({'S',preparedname,0}),4,4)->sendcmd(FLUSHSEND,portal);    } else {    if(plugbuffer)    plugbuffer->sendcmd(KEEP);   #ifdef PG_STATS