Re: Asynchronous queries with bound data.

>
> > 2: Operation system will refuse me to create thousand threads and,
> anyway,
> > database will return responds averagely just when all of them will be
> > accomplished.
>
> I don't know how I can help you, since you haven't explained the
> architecture of your application very well.
>

It does not make a point, but whatever: "application erchitecture" is the
implementation of distributed computing where multiple clients connect to
the server, get it's peace of job, caltulate and returns results back.
Server must track an all (generally speaking) job what was done by each
client (processors' data, adapter's data, amount of accomplished tasks,
calculation time, etc...).

> > 3: I never close a connection once it was created, so any pool will not
> help
> > me (I google says right about "connection pool").
>
> Maybe you should.
>

No I shouldn't. I am the only one user of the database, so I am very welcome
there.

> > Problem can be observed from this abstract point of view:
> > Transferring data from application server (which connects to the
> database)
> > takes 200 ms (and the same amount to transfer backward); adding data to
> the
> > database and then selecting data (all in one request) from it takes 250
> ms,
> > so each database operation (of such type) will take 200 + 250 + 200 = 650
> > ms. Two such operations will take 650 + 650 = 1300 ms, but if there
> existed
> > the way to send two queries at once and then get two results at once (of
> > course tracking the correspondence between requests/responds) we could
> > decrease such two "dialogs" from 1300 ms to 200 + 250 + 250 + 200 = 900
> ms.
> > So, we win 400 ms - when there are thousand requests per several minutes
> -
> > it bocomes to be a very good time.
>
> Databases are optimized for throughput, not latency. It isn't in
> question that there would be less latency if we could parallelise the
> queries

I did not talked (and both requested it) about any kind of some
parallelization - I just meant the database' ability to stack incoming
requests and then pop them one-by-one - just not refusing sending requests
when "there are one already in progress".
And it's not the point to start doing on this direction right now - it will
take weeks or months - and I believe that if it is not implemented already -
so there was some reasons for it - PostgreSQL exist not for the first day
(it's 6 years yonger than me).