| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: multi-threaded pgbench |
| Date: | 2009-07-08 15:56:04 |
| Message-ID: | 4A54C194.9000406@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>
>> Itagaki Takahiro wrote:
>>
>>
>>> Is it acceptable to use pthread in contrib module?
>>>
>> We don't have a precedent it seems. I think the requirement would be
>> that it should compile if pthread support is not present.
>>
>
> My thoughts as well. But I wonder, would it be harder or easier to use
> fork() instead?
>
>
I have just been down this road to some extent with parallel pg_restore,
which uses threads on Windows. That might be useful as a bit of a
template. Extending it to use pthreads would probably be fairly trivial.
The thread/fork specific stuff ended up being fairly isolated for
pg_restore. see src/bin/pg_dump/pg_backup_archiver.c:spawn_restore()
I think you should have it use pthreads if available, or Windows threads
there, or fork() elsewhere.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stefan Kaltenbrunner | 2009-07-08 16:03:09 | Re: multi-threaded pgbench |
| Previous Message | Tom Lane | 2009-07-08 15:46:05 | Re: multi-threaded pgbench |