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

Re: NOLOGGING option, or ?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Neil Conway <neilc(at)samurai(dot)com>,Alvaro Herrera <alvherre(at)surnet(dot)cl>,Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: NOLOGGING option, or ?
Date: 2005-06-01 22:05:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> Not unless you are proposing to change COPY to acquire a lock strong
> >> enough to lock out other writers to the table for the duration ...
> > Well, if the table is initally empty, what harm is there in locking the
> > table?
> You cannot *know* whether it is empty unless you lock the table before
> you look.  So your argument is circular.
> I think this only makes sense as an explicit option to COPY, one of the
> effects of which would be to take a stronger lock than COPY normally does.

One idea would be to look at the table file size first.  If it has zero
blocks, lock the table and if it still has zero blocks, do the no-WAL

I hate to add a flag to a command when we can automatically handle it

Now, you mentioned the idea of doing the optimization in tables that
already have data, and if we do that, we would need a flag because the
lock is stronger than what we have now.

What we could do is to do no-WAL automatically for empty tables (like
when a database is first loaded), and use the flag for cases where the
tables is not zero pages.  The fact is that database loads are a prefect
case for this optimization and old dumps are not going to have that flag
anyway, and automatic is better if we can do it.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-hackers by date

Next:From: Meredith L. PattersonDate: 2005-06-01 22:08:12
Subject: Re: Google's Summer of Code ...
Previous:From: Bruce MomjianDate: 2005-06-01 21:56:07
Subject: Re: NOLOGGING option, or ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group