On Fri, Dec 02, 2005 at 12:15:57AM -0500, Luke Lonergan wrote:
That's good to know - makes sense. I suppose we might still thrash over
a 1GB range in seeks if the BG writer starts running at full rate in the
background, right? Or is there some write combining in the BG writer?
That part your
Tom,
> That analysis is far too simplistic, because only the WAL
> write has to happen before the transaction can commit. The
> table and index writes will normally happen at some later
> point in the bgwriter, and with any luck there will only need
> to be one write per page, not per tuple.
once the table has,
say, 50 million rows.
> -Original Message-
> From: Luke Lonergan [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 01, 2005 9:27 PM
> To: Rick Schumeyer; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] COPY into table too slow with index: n
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> The problem I see is nicely shown by the increase in IOWAIT between the two
> patterns (with and without index). It seems likely that the pattern is:
> A - insert a tuple into the table
> B - insert an entry into the index
> C - fsync the WAL
> - repea
Rick,
On 12/1/05 2:18 PM, "Rick Schumeyer" <[EMAIL PROTECTED]> wrote:
> As a follow up to my own question:
>
> I reran the COPY both ways (with the index and without) while running iostat.
> The following values
> are averages:
> %user %nice %sys %iowait %idle
> no index 39
As a follow up to my own question:
I reran the COPY both ways (with the index
and without) while running iostat. The following values
are averages:
%user %nice %sys %iowait %idle
no index
39 0
2.8 11 47
index
16 1.5 2.1
34
