Re: Idea for nested transactions / savepoints
От | Bruce Momjian |
---|---|
Тема | Re: Idea for nested transactions / savepoints |
Дата | |
Msg-id | 200108051938.f75Jchi27522@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Idea for nested transactions / savepoints (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Idea for nested transactions / savepoints
Re: Idea for nested transactions / savepoints |
Список | pgsql-hackers |
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> The complaints about WAL size amount to "we don't have the disk space > >> to keep track of this, for long-running transactions". If it doesn't > >> fit on disk, how likely is it that it will fit in memory? > > > Sure, we can put on the disk if that is better. > > I think you missed my point. Unless something can be done to make the > log info a lot smaller than it is now, keeping it all around until > transaction end is just not pleasant. Waving your hands and saying > that we'll keep it in a different place doesn't affect the fundamental > problem: if the transaction runs a long time, the log is too darn big. When you said long running, I thought you were concerned about long running in duration, not large transaction. Long duration in one-WAL setup would cause all transaction logs to be kept. Large transactions are another issue. One solution may be to store just the relid if many tuples are modified in the same table. If you stored the command counter for start/end of the nested transaction, it would be possible to sequential scan the table and undo all the affected tuples. Does that help? Again, I am just throwing out ideas here, hoping something will catch. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: