Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: Benchmark Data requested


  • From: Richard Huxton <dev(at)archonet(dot)com>
  • To: Simon Riggs <simon(at)2ndquadrant(dot)com>
  • Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, pgsql-performance(at)postgresql(dot)org, "Jignesh K. Shah" <J(dot)K(dot)Shah(at)sun(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>
  • Subject: Re: Benchmark Data requested
  • Date: Tue, 05 Feb 2008 14:43:36 +0000
  • Message-id: <47A87618(dot)1090203(at)archonet(dot)com>

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.

--
  Richard Huxton
  Archonet Ltd



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group