Re: multi-threaded pgbench

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 16:03:09
Message-ID: 4A54C33D.1060503@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> 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.
>
> Right. Breaking it for non-pthread environments is not acceptable.
>
> The real question here is whether it will be a problem if pgbench
> delivers significantly different results when built with or without
> threading support. I can see arguents either way on that ...

well pgbench as it is now is now is more ore less unusable on modern
hardware for SELECT type queries(way too slow to scale to what the
backend can do thses days and the number of cores in a recent box).
It is only somewhat usable on the default update heavy test as well
because even there it is hitting scalability limits (ie I can easily
improve on its numbers with a perl script that forks and issues the same
queries).
I would even go as far as issuing a WARNING if pgbench is invoked and
not compiled with threads if we accept this patch...

Stefan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2009-07-08 16:30:08 8.4.0 vs. locales vs. pl/perl?
Previous Message Andrew Dunstan 2009-07-08 15:56:04 Re: multi-threaded pgbench