Re: [HACKERS] compression in LO and other fields
| От | Tatsuo Ishii |
|---|---|
| Тема | Re: [HACKERS] compression in LO and other fields |
| Дата | |
| Msg-id | 199911121342.WAA01906@ext04.sra.co.jp обсуждение исходный текст |
| Ответ на | Re: [HACKERS] compression in LO and other fields (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [HACKERS] compression in LO and other fields
|
| Список | pgsql-hackers |
> > It sounds ideal but I remember that Vadim said inserting a 2GB record > > is not good idea since it will be written into the log too. If it's a > > necessary limitation from the point of view of WAL, we have to accept > > it, I think. > > LO won't make that any better: the data still goes into a table. > You'd have 2GB worth of WAL entries either way. What in my mind was LO that is not under the transaction control. I would not say this is a good thing, but I'm afraid we might need this kind of beast in WAL. > The only thing LO would do for you is divide the data into block-sized > tuples, so there would be a bunch of little WAL entries instead of one > big one. But that'd probably be easy to duplicate too. If we implement > big tuples by chaining together disk-block-sized segments, which seems > like the most likely approach, couldn't WAL log each segment as a > separate log entry? If so, there's almost no difference between LO and > inline field for logging purposes. Right. BTW, does anybody know how BLOBs are handled by WAL in commercial DBMSs? --- Tatsuo Ishii
В списке pgsql-hackers по дате отправления: