On Thu, May 24, 2012 at 3:46 PM, Merlin Moncure <mmonc...@gmail.com> wrote:
> On Thu, May 24, 2012 at 2:24 PM, Merlin Moncure <mmonc...@gmail.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?
Yep.
commit 85e2cedf985bfecaf43a18ca17433070f439fb0e
Author: Tom Lane <t...@sss.pgh.pa.us>
Date: Thu Nov 6 20:51:15 2008 +0000
Improve bulk-insert performance by keeping the current target buffer pinned
(but not locked, as that would risk deadlocks). Also, make it work in a sma
ring of buffers to avoid having bulk inserts trash the whole buffer arena.
Robert Haas, after an idea of Simon Riggs'.
But that doesn't help here, since pgbench is only looking up one row per query.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
