Re: NOLOGGING option, or ?

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: NOLOGGING option, or ?
Дата
Msg-id 20050601044007.GD19034@surnet.cl
обсуждение исходный текст
Ответ на Re: NOLOGGING option, or ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: NOLOGGING option, or ?  (Neil Conway <neilc@samurai.com>)
Список pgsql-hackers
On Tue, May 31, 2005 at 10:47:30PM -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > Recent test results have shown a substantial performance improvement
> > (+25%) if WAL logging is disabled for large COPY statements.

> BTW, I'm sure you are the last one who needs to be reminded that
> any such thing breaks PITR completely.  Which is surely sufficient
> reason not to let it be USERSET.

This doesn't work for COPY, but maybe for CREATE TABLE AS we could log
the fact that the command was executed, so the replayer could execute
the same command again.

Of course, this handwaving doesn't explain how the system in recovery
mode would be able to execute a full query to reconstruct the table, and
also it doesn't say a lot about the extra complexity at the source level
to implement this option.

For people loading big files into the database, maybe we could think
about a command to let a file be loaded directly as initial table
content.  So all that we'd need is a program to write the file, which
could be done externally (The filewriter would have to have access to
the catalog and input functions for the involved types, though I think
for simple types it would be straighforward ... we could write frozen
tuples to avoid TransactionId problems.)

-- 
Alvaro Herrera (<alvherre[a]surnet.cl>)
www.google.com: interfaz de línea de comando para la web.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Glaesemann
Дата:
Сообщение: Re: Interval->day proposal
Следующее
От: Michael Glaesemann
Дата:
Сообщение: Re: Interval->day proposal