Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Дата
Msg-id 20051224082342.GA8707@svana.org
обсуждение исходный текст
Ответ на Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and  (Rod Taylor <pg@rbt.ca>)
Ответы Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
On Fri, Dec 23, 2005 at 11:19:01PM -0500, Rod Taylor wrote:
> > In many cases you could use temporary tables, but sometimes you might want
> > multiple processes or multiple transactions to be able to see the data.
>
> Could always implement GLOBAL TEMP tables that have the ability to use
> these kinds of shortcuts.

Indeed, that's the thought I get while reading this thread.

TEMP tables are not xlogged

For global temp tables I'd suggest creating a schema pg_globaltemp or
some such where:

1. No Xlog, like TEMP tables
2. Use shared buffer cache like normal tables.
3. On startup after unclean shutdown, delete anything in that schema

And (AFAIK) we get extra SQL complience to boot. If you really want an
extension, how about one to un-TEMP-ify a temp table.

That would allow the following:

CREATE GLOBAL TEMP TABLE blah INHERITS myhugetable;

-- Load data, munge, etc... no xlog traffic
-- If system crashes here, nothing to recover

ALTER TABLE blah ALTER SCHEMA TO public;  -- untempify

-- If PITR, write Xlog data now
-- If no PITR, just move file and update catalog

How does this not do what people are asking for?
--
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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: Fixing row comparison semantics