Re: pg_xlog becomes extremely large during CREATE INDEX

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_xlog becomes extremely large during CREATE INDEX
Date: 2004-05-15 05:14:11
Message-ID: 20040515051411.GA30420@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, May 15, 2004 at 12:23:18AM -0400, Tom Lane wrote:

> What I see happening on closer analysis is that btree CREATE INDEX can
> hold "exclusive context lock" on some shared buffers for significant
> periods of time. It tries to write all the levels of the btree in
> parallel, so it is spitting out level-zero pages at a great rate,
> level-one pages at a lesser rate, etc. For a large index there could
> be many btree levels, and pages in the higher levels will be held locked
> in the shared buffer arena for considerable periods.

I'm not sure how btree from-scratch-building work, but could it be made
so that it first build level 0 completely, scanning the heap; then build
level 1 scanning the level 0, and so on?

I also wonder why index creation would write XLog information; it won't
be used to recreate the tree if the machine goes down while the index is
created. If you plan on not using the shared bufmgr and issuing a sync
before comit, you could get rid of logging during build ...

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Investigación es lo que hago cuando no sé lo que estoy haciendo"
(Wernher von Braun)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dirk Försterling 2004-05-15 06:39:26 Re: Is Linux 2.6.5 kernel good enough for production?
Previous Message Tom Lane 2004-05-15 04:23:18 Re: pg_xlog becomes extremely large during CREATE INDEX