Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and |
Date | |
Msg-id | 200512290158.jBT1wEK28785@candle.pha.pa.us Whole thread Raw |
In response to | Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and (Martijn van Oosterhout <kleptog@svana.org>) |
Responses |
Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and |
List | pgsql-hackers |
Having read through this thread, I would like to propose a syntax/behavior. I think we all now agree that the logging is more part of the table than the command itself. Right now we have a COPY LOCK patch, but people are going to want to control logging for INSERT INTO ... SELECT, and UPDATE, and all sorts of other things, so I think we are best adding an ALTER TABLE capability. I am thinking of this syntax: ALTER TABLE name RELIABILITY option where "option" is: DROP [ TABLE ON CRASH ]DELETE [ ROWS ON CRASH ]EXCLUSIVESHARE Let me explain each option. DROP would drop the table on a restart after a non-clean shutdown. It would do _no_ logging on the table and allow concurrent access, plus index access. DELETE is the same as DROP, but it just truncates the table (perhaps TRUNCATE is a better word). EXCLUSIVE would allow only a single session to modify the table, and would do all changes by appending to the table, similar to COPY LOCK. EXCLUSIVE would also not allow indexes because those can not be isolated like appending to the heap. EXCLUSIVE would write all dirty shared buffers for the table and fsync them before committing. SHARE is the functionality we have now, with full logging. Does this get us any closer to a TODO item? It isn't great, but I think it is pretty clear, and I assume pg_dump would use ALTER to load each table. The advanage is that the COPY statements themselves are unchanged so they would work in loading into older versions of PostgreSQL. --------------------------------------------------------------------------- Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Mon, Dec 26, 2005 at 12:03:27PM +0000, Simon Riggs wrote: > > I would not be against such a table-level switch, but the exact > > behaviour would need to be specified more closely before this became a > > TODO item, IMHO. > > Well, I think at a per table level is the only sensible level. If a > table isn't logged, neither are the indexes. After an unclean shutdown > the data could be anywhere between OK and rubbish, with no way of > finding out which way. > > > If someone has a 100 GB table, they would not appreciate the table being > > truncated if a transaction to load 1 GB of data aborts, forcing recovery > > of the 100 GB table. > > Ah, but wouldn't such a large table be partitioned in such a way that > you could have the most recent partition having the loaded data. > Personally, I think these "shared temp tables" have more applications > than meet the eye. I've had systems with cache tables which could be > wiped on boot. Though I think my preference would be to TRUNCATE rather > than DROP on unclean shutdown. > > 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. -- End of PGP section, PGP failed! -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
pgsql-hackers by date: