Re: Benchmark Data requested
От | Richard Huxton |
---|---|
Тема | Re: Benchmark Data requested |
Дата | |
Msg-id | 47A87B2E.7050205@archonet.com обсуждение исходный текст |
Ответ на | Re: Benchmark Data requested (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Benchmark Data requested
|
Список | pgsql-performance |
Simon Riggs wrote: > On Tue, 2008-02-05 at 14:43 +0000, Richard Huxton wrote: >> Simon Riggs wrote: >>> On Tue, 2008-02-05 at 15:06 +0100, Dimitri Fontaine wrote: >>>> Le lundi 04 février 2008, Jignesh K. Shah a écrit : >>>>> Multiple table loads ( 1 per table) spawned via script is bit better >>>>> but hits wal problems. >>>> pgloader will too hit the WAL problem, but it still may have its benefits, or >>>> at least we will soon (you can already if you take it from CVS) be able to >>>> measure if the parallel loading at the client side is a good idea perf. wise. >>> Should be able to reduce lock contention, but not overall WAL volume. >> In the case of a bulk upload to an empty table (or partition?) could you >> not optimise the WAL away? That is, shouldn't the WAL basically be a >> simple transformation of the on-disk blocks? You'd have to explicitly >> sync the file(s) for the table/indexes of course, and you'd need some >> work-around for WAL shipping, but it might be worth it for you chaps >> with large imports. > > Only by locking the table, which serializes access, which then slows you > down or at least restricts other options. Plus if you use pg_loader then > you'll find only the first few rows optimized and all the rest not. Hmm - the table-locking requirement is true enough, but why would pg_loader cause problems after the first few rows? -- Richard Huxton Archonet Ltd
В списке pgsql-performance по дате отправления: