Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Sergey Koposov <koposov@ast.cam.ac.uk>
From: Sergey Koposov <koposov@ast.cam.ac.uk>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org, Jeff Janes <jeff.janes@gmail.com>, Stephen Frost <sfrost@snowman.net>
Date: 2012-05-30T20:07:28Z
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 →
-
Improve bulk-insert performance by keeping the current target buffer pinned
- 85e2cedf985b 8.4.0 cited
On Wed, 30 May 2012, Merlin Moncure wrote: > hurk -- ISTM that since IOS is masikng the heap lookups, there must > be contention on the index itself? Does this working set fit in > shared memory? If so, what happens when you do a database restart and > repeat the IOS test? The dataset fits well in shared buffers Here are the data sizes public.idt_photoobservation_small | 521 MB | 528756 public.idt_match_idx | 1084 MB | 528762 public.idt_match_transitid_healpixid_idx | 1522 MB | 1955140 public.idt_match | 2906 MB | 528753 And shared buffers are 10G If I restart the db the timings do not change significantly. There is always some variation which I don't really understand, e.g. the parallel runs sometimes take 18s, or 25 seconds, or 30 seconds per thread. So there is something else affecting the runs -- I don't know, maybe that's related to which thread starts first, or what is the starting point of the seq scan... (there is no other activity on the machine btw). Cheers, S ***************************************************** Sergey E. Koposov, PhD, Research Associate Institute of Astronomy, University of Cambridge Madingley road, CB3 0HA, Cambridge, UK Tel: +44-1223-337-551 Web: http://www.ast.cam.ac.uk/~koposov/