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

Merlin Moncure <mmoncure@gmail.com>

From: Merlin Moncure <mmoncure@gmail.com>

To: Sergey Koposov <koposov@ast.cam.ac.uk>

Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org, Jeff Janes <jeff.janes@gmail.com>, Stephen Frost <sfrost@snowman.net>

Date: 2012-05-30T19:49:26Z

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, May 30, 2012 at 1:45 PM, Sergey Koposov <koposov@ast.cam.ac.uk> wrote:
> On Wed, 30 May 2012, Merlin Moncure wrote:
>>
>>
>> Hm, why aren't we getting a IOS?  Just for kicks (assuming this is
>> test data), can we drop the index on just transitid, leaving the index
>> on transitid, healpixid?    Is enable_indexonlyscan on?  Has idt_match
>> been vacuumed?  What kind of plan do you get when do:
>
>
> Okay dropping the index on transitid solved the issue with indexonlyscan but
> didn't solve the original problem. Actually the indexonlyscan made the
> sequential queries faster but not the parallel ones.

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?

merlin