From: "Carlo Stonebanks" <stonec.register@sympatico.ca>
Subject: Re: pg_exec commit causes extremely long delays
Date: Sat, 28 Oct 2006 17:25:53 -0400
Organization: Hub.Org Networking Services
Lines: 33
Message-ID: <ei0ht9$pok$1@news.hub.org>
References: <20061028160550.13511.qmail@web38906.mail.mud.yahoo.com>
To: pgsql-interfaces@postgresql.org

>I do something similiar, but I don't see these delays. Do you have more 
>details about your circumstance? pgtcl version, PG version, how big the 
>table is, what kind of processing is being done in the script, etc. Have 
>you tried simply debugging in the script to see where the bottleneck may 
>lay? For example, doing a simply puts with clock at various points in the 
>script.

The slowdown is nowhere in the script - it's caused waiting for a return 
from the call pg_exec $cn "commit". The table contains about 400K rows, 
typically with about 10 columns (this varies, as the nature of the import 
application is dynamic).

pgTcl package appears to be 1.5 (assuming the package folder pgtcl1.5 refers 
to v1.5).

The import program imports a "flattened" import file and normalises the 
columns to our enterprise database. All calls to pg_tcl functions are 
wrapped with custom tcl procs we wrote to put a layer of abstraction between 
the code and the sql calls. In fact, these wrap-around procs can swtich from 
pgtcl calls to spi calls so that procs can be re-used in pg server-side TCL 
SP''s. Included in these wrap-around functions is the ability to call 
logging functions which write to log files, telling me the execution taime 
and "explains" for every SQL call, if need be.

If the slowdowns were within TCL code, I would expect Ctrl-C to abort the 
script, but in fact that app is unresponsive to Ctrl-C when the process 
stalls.

PG version is Windows 8.1.2

Carlo