| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
| Date: | 2012-05-24 19:46:37 |
| Message-ID: | CAHyXU0xkrE2adBKFm_T+0PHCwXJTG2CYVZHqsTxSk38g0aMhaw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 24, 2012 at 2:24 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> As you can see, raw performance isn't much worse with the larger data
>> sets, but scalability at high connection counts is severely degraded
>> once the working set no longer fits in shared_buffers.
>
> Hm, wouldn't the BufFreelistLock issue be ameliorated if
> StrategyGetBuffer could reserve multiple buffers so that you'd draw
> down your local list and only then go back to the global pool? (easier
> said than done obviously).
hm, looking at the code some more, it looks like the whole point of
the strategy system is to do that. ISTM bulk insert type queries
would be good candidates for a buffer strategy somehow?
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergey Koposov | 2012-05-24 19:47:10 | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
| Previous Message | Tom Lane | 2012-05-24 19:31:13 | Re: Archiver not exiting upon crash |