Horton

Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

Stephen Frost <sfrost@snowman.net>

View thread
From: Stephen Frost <sfrost@snowman.net>
To: Sergey Koposov <koposov@ast.cam.ac.uk>
Cc: Florian Pflug <fgp@phlo.org>, Merlin Moncure <mmoncure@gmail.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org, Jeff Janes <jeff.janes@gmail.com>
Date: 2012-05-31T00:52:16Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Improve bulk-insert performance by keeping the current target buffer pinned

Sergey, all,

* Sergey Koposov (koposov@ast.cam.ac.uk) wrote:
> I did a specific test with just 6 threads (== number of cores per cpu)
> and ran it on a single phys cpu, it took ~ 12 seconds for each thread,
> and when I tried to spread it across 4 cpus it took 7-9 seconds per
> thread. But all these numbers are anyway significantly better then
> when I didn't use taskset. Which probably means without it the
> processes were jumping from core to core ? ...

It sounds like the issue here really is the PG processes bouncing
between the cores, which I do think is a Linux issue, though perhaps PG
could somehow "encourage" Linux to be better about this somehow..

This isn't specific to Linux, however, under Windows there's something
similar and they encourage the same kind of manual setting of things
like IIS processes to CPUs..

	Thanks,

		Stephen