Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] Re: [GENERAL] postgreSQL multithreading

From: postgre(at)seznam(dot)cz
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Andreas Kretschmer <akretschmer(at)spamfence(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Re: [GENERAL] postgreSQL multithreading
Date: 2008-03-30 18:47:55
Message-ID: 1268.1745-26857-2126107315-1206902875@seznam.cz (view raw or flat)
Thread:
Lists: pgsql-general
Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>  wrote:

> Past discussion here suggests that the backends are strictly single 
> threaded. While you might be able to use multiple threads - I don't know 
> - I expect you'd need to protect all SPI access by a lock that 
> serialized everything anyway.
> 
> Doing it externally with a script / program that uses multiple 
> connections might just be the way. Unfortunately that means that you 
> don't get a single consistent snapshot - each connection will have its 
> own, potentially different, view of the database state.
> 
> A possible use for read only transactions being able to share a snapshot 
> came up in discussion a few weeks ago. I guess this is another one.
> 
> --
> Craig Ringer

I fill tables with observation data, so the tables don't change except the
one for current day. So I don't need to care about different states
of database. 

From what has been posted I think that C function can do the work for me.
But I would still appreciate some peace of code from which I can figure
out how this can be done, because I'm new to database programing.

Thank you

Lukas Houf

In response to

pgsql-general by date

Next:From: Ross BoylanDate: 2008-03-30 18:54:38
Subject: Re: database 1.2G, pg_dump 73M?!
Previous:From: Naz GassiepDate: 2008-03-30 18:37:26
Subject: Re: Locale / Encoding mismatch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group