| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)uk> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net> |
| Subject: | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
| Date: | 2012-05-30 19:49:26 |
| Message-ID: | CAHyXU0xS+c__oHFtDSjh-Qmxi-oHPoZvM2sD73CSU8GsMZa4yw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 30, 2012 at 1:45 PM, Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergey Koposov | 2012-05-30 20:07:28 | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
| Previous Message | Kohei KaiGai | 2012-05-30 19:26:23 | Re: [RFC] Interface of Row Level Security |