Re: [SQL] plpythonu and "hello concurrent world"

Gerardo Herzig <[EMAIL PROTECTED]> writes: > Hi all. Im having some "problems" with a small concurrent plpython function. Don't even *think* about starting multiple threads inside the Postgres backend. It's an excellent way to break things. regards, tom lane

Re: [SQL] marking tuples

Thanks a lot for your reply. I really appreciate it. I will have only one mark field created for the bottommost NewJoin. The other nodes will just use the same mark field. I just want to make sure that flag propagate up the pipeline. Thanks again, ehab > To: [EMAIL PROTECTED] > CC: pgsql-sql@po

Re: [SQL] plpythonu and "hello concurrent world"

Tom Lane wrote: Gerardo Herzig <[EMAIL PROTECTED]> writes: Hi all. Im having some "problems" with a small concurrent plpython function. Don't even *think* about starting multiple threads inside the Postgres backend. It's an excellent way to break things. rega

[SQL] plpythonu and "hello concurrent world"

Hi all. Im having some "problems" with a small concurrent plpython function. Based on a small example [1] about concurrent programming, there is some code which works fine under python: #! /usr/bin/python import threading, random import time def myPrint(str): print 'searching...', str t

Re: [SQL] marking tuples

"Ehab Galal" <[EMAIL PROTECTED]> writes: > In my algorithm, each NewJoin node may "mark" its ps_ResultTupleSlot with > either red/green. I need that mark to flow in the pipeline so that i can > collect them at the top aggregate. How will you tell about the marks from different NewJoins? I think

Re: [SQL] Error OID

Guillaume Lelarge write: > When you run a function for the first time in the session, PostgreSQL > keeps in cache some information... query plans for example. > > > When you run it a second time, it uses the query plan in cache. As > tmpTtlRekening has been drop at the end of the first run, its OI