Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Date
Msg-id 20051227182024.GC32404@svana.org
Whole thread Raw
In response to Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
List pgsql-hackers
On Mon, Dec 26, 2005 at 11:00:51AM -0500, Bruce Momjian wrote:
>
> I think this brings up an interesting distinction, that having the NO
> LOGGING switch per command doesn't make sense because it modifying the
> table.  It has to be a per-object switch, or something that operates
> only on empty tables.  This is the exact same distinction we talked
> about for NO LOGGING COPY.

I've thought of one other possibility, which is kind of at the extreme
end of system implementation. Given the suggestion about not losing a
whole table on unclean shutdown, how about using a single table, split.

1. When setting no logging flag, take exclusive lock and record
filesize. This size is X.
2. From now on any data before X is read-only. So no updates. Any new
data needs to be allocated at end, so no FSM either.
3. Any data added after X is not logged to xlog.
4. On unclean shutdown, truncate table to length X.
5. When logging is reenabled, set X back to infinity.

The shared temp tables discussed earlier and basically be above with
X=0. The process of untempifying a table is setting X to infinity. Temp
tables always have X=0.

This allows people to do their ELT, because they can update rows
written after X but without the logging. If you have PITR you simply
never allow changing X of any table.

But this is pretty way out though IMO.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Handling of build-time enabled GUC settings
Next
From: Greg Stark
Date:
Subject: Re: Online backup vs Continuous backup