On Thu, 14 Jan 2010, fkater(at)googlemail(dot)com wrote:
>> The data needs to be written first to the WAL, in order to provide
>> crash-safety. So you're actually writing 1600MB, not 800.
> I understand. So the actual throughput is 32MB/s which is
> closer to 43 MB/s, of course.
> Can I verify that by temporarily disabling WAL writes
> completely and see if the thoughput is then doubled?
There isn't a magic setting in Postgres to disable the WAL. That would be
far too tempting, and an easy way to break the database.
However, what you can do is to insert the data into the table in the same
transaction as creating the table. Then Postgres knows that no other
transactions can see the table, so it doesn't need to be so careful.
Unfortunately, I don't think even this strategy will work in your case, as
you will be writing to the large object table, which already exists. Could
someone who knows confirm this?
Let's say I go into a field and I hear "baa baa baa". Now, how do I work
out whether that was "baa" followed by "baa baa", or if it was "baa baa"
followed by "baa"?
- Computer Science Lecturer
In response to
pgsql-performance by date
|Next:||From: Matthew Wakeling||Date: 2010-01-15 11:21:28|
|Subject: Re: new server I/O setup|
|Previous:||From: Matthew Wakeling||Date: 2010-01-15 10:55:00|
|Subject: Re: a heavy duty operation on an "unused" table kills my