IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 2 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Well, that explains Postgres
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)\n       37    0.723    0.020    0.723    0.020 storemysql.py:139(_get_conn)\n       37    0.029    0.001    0.029    0.001 storesqlite.py:69(_get_conn)\n\nversus\n\n       37    3.525    0.095    3.525    0.095 storepypgsql.py:55(_get_conn)\n       37    5.524    0.149    5.524    0.149 storepypgsql.py:55(_get_conn)


Wow. I guess libpq on Windows has some serious drawbacks, taking 4 to 8 times as long as MySQL to open a connection, on average.
New You're opening a connection for each iteration?
Pooling is where it's at, ma man... :-)
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New :) It *does* pooling
But it does so optimistically:

1. If there's an (already open) connection in the pool, it gets popped and used.
2. If there isn't a conn ready right away, a new conn is made.
3. When the thread is finished with the conn, it tries to push it into the pool.
4. If the pool is full (mine was max 10), the free conn is closed and discarded.

The 37 connections are far less than the total number of statements. ;) This is *testing* code, ma man.
New Okey Doke
That wasn't entirely clear from the post.

When I use Postgres, I keep my maximum connections very high, on the theory that if I hit a peak once, I'm likely to do it again. Or use a sufficiently slow decay time.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
     Simple ORM data points - (FuManChu) - (4)
         Well, that explains Postgres - (FuManChu) - (3)
             You're opening a connection for each iteration? - (admin) - (2)
                 :) It *does* pooling - (FuManChu) - (1)
                     Okey Doke - (admin)

Menage a dodecahedron?
72 ms