Vadim Mikheev wrote:
>
> > I have committed changes to implement this proposal. I'm not seeing
> > any significant performance difference on pgbench on my single-CPU
> > system ... but pgbench is I/O bound anyway on this hardware, so that's
> > not very surprising. I'll be interested to see what other people
> > observe. (Tatsuo, care to rerun that 1000-client test?)
>
> What is your system? CPU, memory, IDE/SCSI, OS?
> Scaling factor and # of clients?
>
> BTW1 - shouldn't we rewrite pgbench to use threads instead of
> "libpq async queries"? At least as option. I'd say that with 1000
> clients current pgbench implementation is very poor.
Would it be useful to run a test like the AS3AP benchmark on this to
look for performance measurements?
On linux the Open Source Database Benchmark (osdb.sf.net) does this, and
it's multi-threaded to simulate multiple clients hitting the database at
once. The only inconvenience is having to download a separate program
to generate the test data, as OSDB doesn't generate this itself yet. I
can supply the test program (needs to be run through Wine) and a script
if anyone wants.
???
>
> BTW2 - shouldn't we learn if there are really portability/performance
> issues in using POSIX mutex-es (and cond. variables) in place of
> TAS (and SysV semaphores)?
>
> Vadim
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there." - Indira Gandhi